I’ve been pretty busy with real life as I’m sure everyone is these days… over the summer you likely didn’t notice that the SSL certificate expired on this website. I eventually got around to manually renewing the Let’s Encrypt wildcard SSL certificate because I didn’t have time right then to dig into why my monthly cronjob wasn’t working properly. I realize I’m about 5 – 6 months late on this story but hey it’s my story for today.

It’s Friday and some much needed personal time off and since it’s raining outside I’m left to deal with anything that needs attention inside the house… having emptied all the mouse traps in the garage (that time of year here in Pennsylvania) and having already made my trip to the bank and to the DMV I’m left with digital maintenance – did I mention I built a new PC – no I didn’t did I, I really need to catch up on this blog.

Anyway, back to Let’s Encrypt and GoDaddy… upon digging into the code I find that the API call to GoDaddy is failing with the following message:

{"code":"ACCESS_DENIED","message":"Authenticated user is not allowed access"}

Interesting, let me see if GoDaddy expires the API key or secret like LinkedIn likes to-do, perhaps I’ll just regenerate them regardless. After a new API key and secret still no luck, even calling the API via cURL returns the same error message. A quick search of Google quickly reveals a few stories that cause some concern…

• GoDaddy ACCESS DENIED via API-Call
• GoDaddy no longer allows API access to clients (e.g. for DNS-based cert renewal) if you have less than 50 domains

It would seem that GoDaddy removed access via their API for smaller customers? They probably notified me and I just missed the email message, after all I’m pretty busy. Hmm… nope they didn’t notify me, seven years of email archives and nothing from GoDaddy about them restricting access to their API. I do have a message from them in March of 2022 asking if it was me setting up the original API key and secret. Disappointing but that seems to be the trend for 2024, vendor after vendor and don’t get me started on the Private Equity mess. For the record I have 7 domains with GoDaddy and have been using them since 2007.

I think it’s time to let my money do the talking, even if it requires more of my personal time than I have to offer – it’s really the only voice any of us have.

What do you think?

Cheers!

Who doesn’t love a good mystery, I’m no exception. A few weeks back we had an interesting issue pop-up. It was midnight on a Sunday night and PagerDuty started firing off an alert that a UPS in one of our distribution centers had just stopped responding via HTTPS. The UPS was still online responding to both ICMP and SNMP traffic, so the alert was acknowledged and the alarm was paused until it could be reviewed the next day.

The UPS itself was fairly new having been installed just under a year ago. It was an Schneider Electric/APC 3000RT Smart-UPS with an AP9631 network management card. Interestingly enough we just had an issue with a brand new APC 8000SRT Smart-UPS with an integrated AP9537SUM network management card that had essentially started doing the same exact thing a few days earlier. Only that installation was only a few days old when it stopped working. Again ICMP and SNMP worked fine… as did HTTP (if you enabled it).

What was that all about?

After a few hours of troubleshooting and digging I discovered that the self-signed SSL certificate installed on the NMC had expired. Any attempt to connect to the NMC via HTTPS after that point would result in the socket getting immediately closed upon connecting by the NMC. Removing the self-signed SSL certificate and rebooting the NMC caused the self-signed SSL certificate to be regenerated and the problem was resolved. You can remove the SSL certificate by enabling the HTTP server via either SSH or TELNET (will depend on the age of your card as to which one is enabled by default), login in via HTTP go to Configuration -> Network -> Web -> SSL Certificate and select Remove and Apply. You just need to reboot the NMC and you should be able to connect via HTTPS.

1 Year?

The self-signed SSL certificate is only good for one year, after which you’ll need to regenerate it again. The latest version of the firmware/software (NMC2 – v7.0.4) from APC sets the expiration date for all self-signed SSL certificates out to 2035 – not sure if the web browsers will start to complain about that.

Ripple20?

If you haven’t already patched your APC network management cards it might be a good time to take care of that task as well. We had to patch all of our APC and Eaton network management cards that are used throughout our network.

• https://www.apc.com/us/en/faqs/FA410359/
• https://www.eaton.com/content/dam/eaton/company/news-insights/cybersecurity/security-bulletins/eaton-security-bulletin-treck-tcp-ip-stack-vulnerabilities-ripple20.pdf

Cheers!

We’ve all had SSL certificates expire… however, some are more important than others and have a much broader impact. In February 2020 Microsoft had a certificate expire that brought down Teams as reported by the Engadget in an article titled, Microsoft Teams went down because of an expired certificate. The SSL certificate on the discussion forums that I still maintain was set to expire tomorrow so I thought I should replace it. I could have used Let’s Encrypt for free but I chose to use RapidSSLonline, as it was only $14.99/year for 2 years. I’ve seen too many websites with expired Let’s Encrypt SSL certificates when certbot goes awry or someone forgets to manually renew the certificate every 90 days.

There are hundreds of posts, articles, blogs, video on this topic so I’m going to be extremely brief here. In this case I decided to generate a new private key and essentially a new certificate for forums.networkinfrastructure.info even though I was technically renewing the certificate. I purposely like to keep the FQDNs in the certificate filenames and I keep the files in /etc/ssl/certs for reference in any Apache or Nginx configuration files. For the example below I’ll use my.domain.com to keep the text manageable.

openssl genrsa -out my.domain.com.key 4096
openssl req -new -key my.domain.com.key -out my.domain.com.csr
cat my.domain.com.csr

I went online to RapidSSLonline and ordered a SSL certificate, completed the domain validation via email and then cut-n-pasted the contents of the certificate signing request (my.domain.com.csr) into their portal. Waited for the validation and generation and then downloaded the SSL certificate which I stored in a file called my.domain.com.crt. I also downloaded the certificate for the intermediate root, which in this case was for RapidSSL RSA CA 2018. The intermediate root, if any, will change depending on who you use to purchase the SSL certificate.

In order to make sure the certificate chaining was correct, I had to copy the intermediate root certificate along with the certificate I had just downloaded in a single file (bundle).

cat my.domain.com.crt > bundle.my.domain.com.crt
cat intermediate.crt >> bundle.my.domain.com.crt

I used the filename bundle-my.domain.com.crt and then copied the private key and the bundle to my server so I could update the Nginx configuration.

ssl_certificate     /etc/ssl/certs/bundle-my.domain.com.crt;
ssl_certificate_key /etc/ssl/certs/my.domain.com.key;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers EECDH+AESGCM:EDH+AESGCM:ECDHE-RSA-AES128-GCM-SHA256:AES256+EECDH:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/ssl/certs/dhparams.pem;

With that done I checked the Nginx configuration file;

service nginx configtest

And then performed a restart to push the change into production;

service nginx restart

The last step was to visit SSL Shopper to verify the certificate and chaining was all good.

Any questions, let me know.

Cheers!

*/15 * * * * wget http://blog.michaelfmcnamara.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

There are a few issues with this… wget was not following the redirect from HTTP to HTTPS after I forced HTTPS/SSL as the default for all traffic. And since I was using multiple virtual hosts behind a single IP address I was relying on SNI and the HTML headers to determine which virtual host the request should be delivered to.

Here’s what I’m running today in my cron;

*/15 * * * * curl --header 'Host: blog.michaelfmcnamara.com' https://blog.michaelfmcnamara.com/wp-cron.php?doing_wp_cron=true > /dev/null 2>&1

If you are forcing all traffic to SSL you might want to check any old links you have lying around and if you are using SNI you’ll definitely need to attach the proper host headers to the HTTP request.

Cheers!

We need to generate the following pieces:

1. Generate a private key for this specific use
2. Using the private key generate Certificate Signing Request (CSR)
3. Have the CSR signed by a private or public Certificate Authority which will provide the certificate
4. Upload the private key and signed certificate to your device or system.

Let’s start by creating a directory just for this specific certificate, makes it easier to track all the files we’ll have when we’re complete. In this example I’m going to request a certificate for a Cisco ASA to be used with the Cisco AnyConnect VPN client, vpn.acme.com.

mkdir ~/vpn.acme.com/
cd ~/vpn.acme.com/

Let’s generate a private key, using a key size of 4096 which should future proof us sufficiently.

openssl genrsa -out vpn.acme.com.key 4096

Now let’s generate a SHA 256 certificate request using the private key we generated above.

openssl req -new -sha256 -key vpn.acme.com.key -out vpn.acme.com.csr

We now need to take the certificate request and have that signed by a Certificate Authority. The resulting certificate (filename: vpn.acme.com.crt) will need to be installed along with the private key onto the appliance or device that we’re generating the certificate for.

Since we’re working with a Cisco ASA we need to combine the private key, certificate and any intermediate certificate authorities into a single PKCS12 file so we can upload that file into our Cisco ASA. Again we’ll use OpenSSL for this task and it’s pretty easy. (You’ll be prompted to set a password on the file, make sure you don’t forget it because you’ll need it to upload the file into the Cisco ASA).

openssl pkcs12 -export -in vpn.acme.com.crt -inkey vpn.acme.com.key \
        -certfile public-intermediate-ca.crt -out vpn.acme.com_bundle.p12

Now we can upload the bundle file (vpn.acme.com_bundle.p12) to the Cisco ASA.

Cheers!

It was a simple task, replace the SSL certificate for the discussion forums since it was soon expiring. Renewing the certificate from RapidSSL was a relatively easy task. I uploaded the new intermediate root and certificate files to the server, bundled them together into a single file and modified the Nginx configuration and proceeded to restart the Nginx process. Oddly enough after I restarted the Nginx process I got an “ERR_CONNECTION_REFUSED” from Chrome. A quick test via cURL provided the same result, “connection refused“. I backed out the configuration change and restarted Nginx only to still have the same problem. I thought, “now that is very odd indeed”. I had backed out the configuration change yet I was still having an issue. I quickly realized that the problem was impacting all the websites I managed on that specific server and it appeared that any HTTP or HTTPS connections were getting refused, I confirmed this from a packet trace by observing a TCP reset packet being sent by the server upon receipt of a SYN packet from the client. I checked to see that Nginx was listening on TCP/80 and TCP/443 and it was listening on both ports [Example: lsof -i / netstat -an]. I got a hint when I checked the IPv6 address using cURL and got a response. Nginx was answering IPv6 requests but essentially ignoring IPv4 requests. Something else must have changed outside of the simple certificate configuration change that I had already rolled back.

A quick look at yum revealed that Nginx was updated back on September 10th, that was a significant find.

[root@centos ~]# yum history
Loaded plugins: fastestmirror
ID     | Login user               | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
    42 | root               | 2016-09-10 09:45 | I, U           |   36 EE
    41 | root               | 2016-05-26 10:50 | I, U           |  137 EE
    40 | root               | 2016-03-13 12:38 | Update         |   19
    39 | root               | 2016-02-06 07:09 | Update         |   10
    38 | root               | 2015-12-25 09:31 | Update         |   39

[root@centos ~]# yum history info 42
Loaded plugins: fastestmirror
Transaction ID : 42
Begin time     : Sat Sep 10 09:45:34 2016
Begin rpmdb    : 378:4a758e818516d25c4ae06da426d3b43ef7f5624a
End time       :            09:45:51 2016 (17 seconds)
End rpmdb      : 385:489132724582a1c351cce4cf9ac0efa1a7fe4898
User           : root 
Return-Code    : Success
Command Line   : update
Transaction performed with:
    Installed     rpm-4.8.0-55.el6.i686                         @base
    Installed     yum-3.2.29-73.el6.centos.noarch               @base
    Installed     yum-plugin-fastestmirror-1.1.30-37.el6.noarch @base
Packages Altered:
    Updated     GeoIP-GeoLite-data-2015.12-1.el6.noarch       @epel
    Update                         2016.07-1.el6.noarch       @epel
    Updated     GeoIP-GeoLite-data-extra-2015.12-1.el6.noarch @epel
    Update                               2016.07-1.el6.noarch @epel
    Updated     avahi-libs-0.6.25-15.el6.i686                 @base
    Update                 0.6.25-15.el6_8.1.i686             @updates
    Updated     cronie-1.4.4-15.el6_7.1.i686                  @base
    Update             1.4.4-16.el6_8.2.i686                  @updates
    Updated     cronie-anacron-1.4.4-15.el6_7.1.i686          @base
    Update                     1.4.4-16.el6_8.2.i686          @updates
    Updated     httpd-2.2.15-53.el6.centos.i686               @base
    Update            2.2.15-54.el6.centos.i686               @updates
    Updated     httpd-tools-2.2.15-53.el6.centos.i686         @base
    Update                  2.2.15-54.el6.centos.i686         @updates
    Updated     initscripts-9.03.53-1.el6.centos.i686         @base
    Update                  9.03.53-1.el6.centos.1.i686       @updates
    Updated     innotop-1.10.0-0.3.81da83f.el6.noarch         @epel
    Update              1.11.1-1.el6.noarch                   @epel
    Updated     libtiff-3.9.4-10.el6_5.i686                   @base
    Update              3.9.4-18.el6_8.i686                   @updates
    Updated     libxml2-2.7.6-21.el6.i686                     @base
    Update              2.7.6-21.el6_8.1.i686                 @updates
    Updated     libxml2-python-2.7.6-21.el6.i686              @base
    Update                     2.7.6-21.el6_8.1.i686          @updates
    Updated     nginx-1.0.15-12.el6.i686                      @epel
    Update            1.10.1-1.el6.i686                       @epel
    Dep-Install nginx-all-modules-1.10.1-1.el6.noarch         @epel
    Updated     nginx-filesystem-1.0.15-12.el6.noarch         @epel
    Update                       1.10.1-1.el6.noarch          @epel
    Dep-Install nginx-mod-http-geoip-1.10.1-1.el6.i686        @epel
    Dep-Install nginx-mod-http-image-filter-1.10.1-1.el6.i686 @epel
    Dep-Install nginx-mod-http-perl-1.10.1-1.el6.i686         @epel
    Dep-Install nginx-mod-http-xslt-filter-1.10.1-1.el6.i686  @epel
    Dep-Install nginx-mod-mail-1.10.1-1.el6.i686              @epel
    Dep-Install nginx-mod-stream-1.10.1-1.el6.i686            @epel
    Updated     nss-softokn-3.14.3-23.el6_7.i686              @base
    Update                  3.14.3-23.3.el6_8.i686            @updates
    Updated     nss-softokn-freebl-3.14.3-23.el6_7.i686       @base
    Update                         3.14.3-23.3.el6_8.i686     @updates
    Updated     php-5.3.3-47.el6.i686                         @base
    Update          5.3.3-48.el6_8.i686                       @updates
    Updated     php-cli-5.3.3-47.el6.i686                     @base
    Update              5.3.3-48.el6_8.i686                   @updates
    Updated     php-common-5.3.3-47.el6.i686                  @base
    Update                 5.3.3-48.el6_8.i686                @updates
    Updated     php-fpm-5.3.3-47.el6.i686                     @base
    Update              5.3.3-48.el6_8.i686                   @updates
    Updated     php-gd-5.3.3-47.el6.i686                      @base
    Update             5.3.3-48.el6_8.i686                    @updates
    Updated     php-mysql-5.3.3-47.el6.i686                   @base
    Update                5.3.3-48.el6_8.i686                 @updates
    Updated     php-pdo-5.3.3-47.el6.i686                     @base
    Update              5.3.3-48.el6_8.i686                   @updates
    Updated     python-2.6.6-64.el6.i686                      @base
    Update             2.6.6-66.el6_8.i686                    @updates
    Updated     python-libs-2.6.6-64.el6.i686                 @base
    Update                  2.6.6-66.el6_8.i686               @updates
    Updated     tar-2:1.23-14.el6.i686                        @base
    Update          2:1.23-15.el6_8.i686                      @updates
    Updated     tzdata-2016d-1.el6.noarch                     @updates
    Update             2016f-1.el6.noarch                     @updates
    Updated     udev-147-2.73.el6.i686                        @base
    Update           147-2.73.el6_8.2.i686                    @updates
    Updated     yum-3.2.29-73.el6.centos.noarch               @base
    Update          3.2.29-75.el6.centos.noarch               @updates
Scriptlet output:
   1 warning: /etc/nginx/conf.d/default.conf created as /etc/nginx/conf.d/default.conf.rpmnew
   2 warning: /etc/nginx/nginx.conf created as /etc/nginx/nginx.conf.rpmnew
history info

This was the first time I had restarted Nginx since the update back in September, and that was the key to unlocking the mystery. I tried backing out the update

yum history undo 42

but that left me without Nginx installed at all. I suspected something changed in Nginx with the update, I know that the server was responding to IPv6 requests but not IPv4 requests so I started looking at the configuration files for the virtual hosts and quickly focused on my use of a single listen directive for both IPv4 and IPv6.

    listen              [::]:80;

I looked back at the server logs and determined that Nginx was upgraded from 1.0.15-5 to 1.10.1 back in September. It turns out that as of 1.3.4, the ipv6only directive is enabled by default which disables IPv4. While doing some research I also stumbled across an article from Michael Hughes titled ‘Nginx ipv6only setting gotcha‘ which described the same issue I was experiencing.

I adjusted the configuration of my virtual hosts by using the following;

    listen 80;
    listen [::]:80;

I had planned to spend about 30 minutes replacing the SSL certificate, after almost 2 hours of downtime I finally managed to get the websites up and running again. This is par for the norm working in Information Technology, you usually need to be a part-time detective to figure out what broke before you can fix anything. I eventually got back around to replacing the SSL certificate and that worked without issue.

Cheers!

Articles

Network Field Day #NFD11 by Dominik Pickhardt – Dominik will be attending Network Field Day 11 this January 2016 in San Jose, CA. It just happens that I’ve also been invited to join the gang in Silicon Valley on January 19th – 22nd. You find more information over on the Tech Field Day website.

US House okays making internet tax exemptions permanent by Shaun Nichols – We’ll need to see how HR 644 fairs in the senate now that it includes a provision to prevent states from collecting sales tax on Internet retailers for out of state customers.

IP leak affecting VPN providers with port forwarding by Perfect Privacy – The team over at Perfect Privacy have revealed how an attacker can reveal a VPN user’s real IP address given a few specific conditions.

A free, almost foolproof way to check for malware by Roger A. Grimes – A great article describing how to easily test a Windows client to see if it’s infected with some malware. I’ve recently found myself doing quite a bit of security forensics analyzing various systems and images.

Will Let’s Encrypt threaten commercial certificate authorities? by Larry Seltzer – Let’s Encrypt is a new free Certificate Authority looking to make publicly signed certificates available for free to anyone. The stated goal of the organization is to help secure the Internet by offering free SSL certificates to anyone. The certificates are only valid for 90 days, a significant caveat and differentiator with the commercial certificate authorities.

Cheers!

In addition, Google has been using HTTP/HTTPS signals in their ranking for quite a few months now. Not sure if that will have any impact on my little blog but I’m happy to try and push that percentage of sites using HTTPS/SSL just a little higher.

I purchased a wildcard SSL certificate from RapidSSL that covers *.michaelfmcnamara.com. I have multiple servers and virtual hosts so it only made sense to purchase a wildcard certificate instead of purchasing multiple individual certificates.

The installation was pretty simple, I did need to bundle all the certificates including the root GeoTrust Global CA, the intermediate RapidSSL SHA265 CA – G3 and then my certificate into the certificate file so the browser was presented the proper SSL chaining. I changed the WordPress Address and Site Address URLs from within WordPress and then I setup a redirect from Nginx;

server {
    listen              [::]:80;
    server_name         blog.michaelfmcnamara.com mirror.michaelfmcnamara.com;

    return 301 https://$server_name$request_uri;
}

I also had to make a few small changes to the Google Adsense scripts.

Any Issues?

Yes, there will be a few issues… Internet Explorer 8 for Windows XP doesn’t support SNI (Server Name Indicator) so that browser won’t be able to connect now that I’ve enabled two SSL enabled sites on the same IP address using two different certificates in Nginx. If you are still using Internet Explorer 8 on Windows XP you should really consider migrating off Windows XP.

Are you going to enable HTTPS/SSL on your blog or website?

Cheers!

Update: December 30, 2015 –  I had issues uploading images via WordPress after turning on the HTTP redirect. I was getting the error “An error occurred in the upload. Please try again later.” when I tried to upload an image via HTTPS/SSL. I had to go into wp-config.php and add the following, “define(‘FORCE_SSL_ADMIN’, true);” which appears to have resolved the problem.

I quickly found that cURL was having issues connecting to https://forums.networkinfrastructure.info without any parameters;

[root@mars certs]# curl -v https://forums.networkinfrastructure.info/.xml/?type=rss
* About to connect() to forums.networkinfrastructure.info port 443 (#0)
*   Trying 162.243.40.10... connected
* Connected to forums.networkinfrastructure.info (162.243.40.10) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -5961
* Closing connection #0
* SSL connect error
curl: (35) SSL connect error

Initially I thought I had a certificate issue, concerned that either the GEO Trust root certificate and/or intermediate RapidSSL SHA256 certificate might be missing from /etc/pki/tls/certs/ca-bundle.crt but I was able to quickly rule that problem out using the -k flag on cURL. I noticed that if I tell cURL to use TLS 1.2 then it can connect without issue;

[root@mars certs]# curl -v --tlsv1.2 https://forums.networkinfrastructure.info/.xml/?type=rss
* About to connect() to forums.networkinfrastructure.info port 443 (#0)
*   Trying 162.243.40.10... connected
* Connected to forums.networkinfrastructure.info (162.243.40.10) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
* Server certificate:
*       subject: CN=forums.networkinfrastructure.info,OU=Domain Control Validated - RapidSSL(R),OU=See www.rapidssl.com/resources/cps (c)14,OU=GT54191003
*       start date: Jul 16 16:20:24 2015 GMT
*       expire date: Nov 26 12:10:44 2016 GMT
*       common name: forums.networkinfrastructure.info
*       issuer: CN=RapidSSL SHA256 CA - G3,O=GeoTrust Inc.,C=US
> GET /.xml/?type=rss HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: forums.networkinfrastructure.info
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.0.15
< Date: Sat, 26 Dec 2015 14:23:13 GMT
< Content-Type: application/rss+xml; charset=ISO-8859-1
< Transfer-Encoding: chunked
< Connection: keep-alive
< X-Powered-By: PHP/5.3.3
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1
< X-Content-Type-Options: nosniff
< Set-Cookie: PHPSESSID=tfvh4sti8ks08l6n6o61sd46n5; path=/
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Pragma: no-cache
< Cache-Control: private
<

        
                Network Infrastructure Forums
                https://forums.networkinfrastructure.info/index.php
                            
...
...

So there’s some issue with cURL negotiating between SSLv3, TLS 1.0, TLS 1.1 and TLS 1.2. I turned to Google and found way to many bug reports and issues with how cURL tries to negotiate the transport layer security protocol. There’s a lengthy discussion regarding bug 1170339 concerning cURL’s default behavior on a RedHat/CentOS client and covers the exact scenario I’m experiencing.

I decided to turn my attention to the server configuration, perhaps I could find a quick fix in the server configuration, because a client fix might work for this specific client but would still be present for anyone else on the Internet using the same client software.

Here’s what my ngnix configuration looks like on the server side;

    #SSL
    ssl_certificate     /etc/ssl/certs/bundle-forums.networkinfrastructure.info.sha256.crt;
    ssl_certificate_key /etc/ssl/certs/private.key;
    ssl_session_timeout 5m;
    ssl_protocols TLSv1.1 TLSv1.2;
    ssl_ciphers ALL:!EXPORT:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP;
    ssl_prefer_server_ciphers on;

I recall recently removing TLS 1.0 support from the Nginx configuration file so I’m guessing I broke it myself (funny how that’s usually the case).

I went back and did some additional research around best practices for SSL protocols and ciphers and modified my Nginx configuration file with the following settings;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers EECDH+AESGCM:EDH+AESGCM:ECDHE-RSA-AES128-GCM-SHA256:AES256+EECDH:DHE-RSA-AES128-GCM-S
HA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-R
SA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256
:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:A
ES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EX
PORT:!DES:!MD5:!PSK:!RC4;

I restarted Nginx and then ran a quick test from Qualys SSL Labs to validate the changes and found that I needed to make an additional config tweak to close a Diffie-Hellman issue. With that complete I the server was now scoring an A from the Qualys SSL Lab testing and it was answering TLS 1.0 requests from cURL.

Another 5 minute problem closed 2+ hours later.

Cheers!

When you’d visit the forums you’d noticed a yellow triangle on the top of the padlock at the top of the browser instead of the traditional green padlock.

What’s the problem with SHA-1 certificates?

It’s believed that by 2018 the computing power may be available to render SHA-1 certificates vulnerable to attack. While MD5 has already proven to be cryptographically weak algorithm given the available compute resources available today, the move from SHA-1 to SHA-2 (SHA256) is really focused on future proofing our security.

How did you do it?

It was pretty straight forward, I generated a new SHA256 CSR from my host using OpenSSL,

openssl req -new -key private.key -sha256 -out forums.networkinfrastructrure.info.sha256.csr

I went to the RapidSSL homepage and clicked on “Reissue SSL” on the right hand side of the page. I provided the necessary information, validated my ownership of the domain, uploaded the new CSR and then download the new certificate. I uploaded that new certificate along with the new intermediate certificate authority to my host and replaced the certificate file within the Nginx configuration file. All that was left to-do was to restart Nginx (service nginx restart) and validate that everything was working.

Cheers!

Image Credit: Carsten Mueller

I’ve been wanting to-do this for sometime now but only found the time over the holidays to make the necessary changes and test everything. This will help guarantee that the user credentials you use to login along with the session cookie will now be secure from potential eavesdropping.

I’m running Simple Machines Forum software on the discussion forums and while it doesn’t “support” HTTPS/SSL nativly it’s not hard to set everything up manually. Here are the steps I took to enable HTTPS/SSL for Simple Machines Forum.

1. Purchase certificate from RapidSSL
2. Install certificate into Nginx web server configuration.
3. Change base URL using repair_settings.php
4. Change Google Adsense code to HTTPS
5. Change Statcounter code to HTTPS
6. Test

I’m using Nginx and Server Name Indication (SNI) so you’ll need a fairly modern web browser.

Cheers!

Update: Tuesday January 6, 2015 @ 6:00PM

As I suspected some of the URLs that the PrettyURLs mod was re-writing were getting set back to HTTP. I found the solution documented on the PrettyURL homepage/wiki. I added a file called fix.php into the root of my webserver with the following contents;

<?php
require_once(dirname(__FILE__) . '/SSI.php');
require_once($sourcedir . '/Subs-PrettyUrls.php');
updateSettings(array('pretty_root_url' => $boardurl));
pretty_update_filters();
?>

I then executed that code by calling the URL from a web browser after which I removed the file.

With that step done now all the links in the HTML source are correct and everything is working properly.

Update: Tuesday January 6, 2015 

I’ve discovered that this change is going to require some additional work. A number of links are still pointing toward HTTP as opposed to HTTPS. I went to the effort this evening to dump the MySQL database and search and replace all links with the HTTPS variant. I was hoping this change would help fix a few other problems, unfortunately not. If you look at the source HTML you’ll see that a few of the links are still holding on to the http://forums.networkinfrastructure.info as opposed to the https://forums.networkinfrastructure.info. I believe the PrettyURLs mod is writing some of the links but it’s using HTTP as opposed to HTTPS. Now I need to dig down into the code and determine what’s broken and where.

Image Credit: Mike Cooke

I received the following notification this week that informs Verizon customers that Verizon’s Email servers are now supporting SSL when utilizing POP3 and SMTP to send and receive email from a traditional email client such as Mozilla’s Thunderbird,  Microsoft’s Outlook or your Android or Apple Smartphone.

This is very exciting news because you hopefully already know that your username and password are sent in the clear when utilizing POP3 and SMTP (with authentication) when not utilizing SSL. So the answer to the ages old question of does Verizon support SSL encryption has changed? They now support SSL encryption on both the POP3 (receiving) and SMTP (sending) for traditional email clients.

I made the changed to my Microsoft Outlook client and it works perfectly.

You’ll need to dig deep into the settings to modify the port numbers that are utilized for both POP3 and SMTP, they can be found under “More Settings…”

You can find additional configuration information on Verizon’s website at this link.

I also recently noticed that Verizon now redirects any attempts to connect to http://webmail.verizon.net to the SSL secured site at https://webmail.verizon.net which again is very exciting from a security perspective.

Now you can safely utilize that public hotspot or guest network without worrying if someone is going to steal your username and password when you try and check your inbox. This change is long overdue and very welcome in my opinion.

Cheers!

Update: March 20, 2013

I just noticed that Verizon is only encrypting the actual login (passing the user credentials). They are not encrypting the entire session which includes the actual contents of the message or any attachments. This approach was helpful 5 years ago but not today, I’m not sure if Verizon is using secure COOKIES or not but this approach is usually susceptible to session hijacking.

You might recall that I wrote about software release 6.5R2 back in December 2009, detailing our troubles with the 6.5R1 software release and our hope that Juniper could save the day.

Thankfully I’m hear to tell that software release 6.5R2 for the Juniper Secure Access SSL VPN appliances appears to be a winner!

About six days ago I upgraded a pair of SA4000s running 6.5R1 to 6.5R2. The primary goal was to resolve the compatibility issues that were introduced in 6.5R1 and finally provide support for both Windows Vista 64-bit and Windows 7 64-bit. The actually upgrade of the appliances was pretty straight forward and the initial testing didn’t reveal any issues. Unfortunately there’s no amount of testing can always predict how things will go when working with home personal computers and the myriad of software available. We waited nervously for the first few days… thankfully the calls never came. While we had one or two users that needed some hand holding during the software upgrade/installation process, the majority of our 800+ users didn’t seem to have any issues whatsoever.

Let me congratulate Juniper Networks on a job well done!

I’ve created discussion forum for anyone that would like to discuss the Juniper Secure Access SSL VPN appliances. If you have a question or would like to make a comment why not join the discussion?

Cheers!

• Juniper SSL VPN Secure Access 6.5 Available
• Norton 360 and Juniper SSL VPN WSAM
• Juniper SSL VPN Upgrade – Client Software
• Juniper SSL VPN Appliance and Windows Vista 64-Bit

I will be testing 6.5R2 on a spare SA4000 appliance (waiting for an evaluation license key from Juniper) and will share my results with everyone here.

You can find the release notes for 6.5R2 here.

Windows 7

When will Juniper Network’s SSL VPN (SA platform/IVE OS) support Microsoft’s Windows 7 OS as a supported client platform? You can refer to Juniper knowledge base article, KB13195.

Juniper states that “Microsoft Windows 7 is qualified” (not supported) on 6.5R2 and there should be no major issues aside from the know caveats/issues.

Known Issues/Caveats:

* All client components:

1. 1. Unable to install (or) launch client component using IE8 (64 bit). This is expected as IE8 (64 bit) browser is not supported. Please use IE8 (32 bit) to avoid this issue. (470316)

* EndPoint Integrity:

1. When using IE 8 on 64-bit Windows 7 the reason string is not available when a patch assessment policy fails. (485421)

* Secure Virtual Workspace (SVW):

1. When opening a file with Windows Photo Viewer inside SVW, the file is shown on the real desktop rather than inside the SVW session. (447409)
2. On Windows 7, saving a MS Office 2003 file inside SVW fails. (486104)
3. On Windows 7, Control Panel is accessible inside SVW even if it is disabled under application to allow list. (486104)

* WSAM:

1. If Kaspersky Anti-Virus Version 2009 (8.0.0.506) is installed on a Windows 7 (OR) Windows Vista computer, WSAM will not be able to intercept and secure traffic. This issue is not seen with older versions of Kaspersky Anti-Virus (434715).

Cheers!

Update: January 6, 2009

I should point out that I’ve discovered that JSAM will not launch properly with Windows 7 (64-bit) when running 6.5R1 software. I initially thought it might have something to-do with the 32-bit/64-bit versions of Internet Explorer or the 32-bit/64-bit versions of the Java Runtime Environment. I tested the same machine today with 6.5R2 and it worked fine using the 32-bit version of Internet Explorer. I didn’t try the 64-bit version of Internet Explorer. So it would appear the problem is resolved in 6.5R2 software, please see the forums for additional details.

This latest version of software now supports Windows Secure Application Manager (WSAM) when used on Windows XP 64-bit and Windows Vista 64-bit clients. There was no mention of Windows 7 which is due to be released October 22, 2009. I did find it interesting that Internet Explorer 8 was only “compatible” with respect to a few of the features while Internet Explorer 7 was “qualified” with all features (review Juniper Secure Access 6.5 Supported Platforms document for specifics). I did a quick search over in the Juniper forums and found some reports that Host Checker wasn’t working properly with Windows 7 RC.

There were two new features that jumped out at me in the What’s New document;

RDP Launcher

SA 6.5 simplifies the use of RDP sessions for end users without requiring them or administrators to create bookmarks.

• Simplifies ease of use for remote users to RDP into remote desktops by merely clicking a button or entering a hostname or IP Address of the remote computer.
• Simplifies the configuration for administrators and reduces the number of support calls from users who are unable to figure out how to RDP to remote computers.

VDI Support

Secure Access (SA) version 6.5 interoperates with VDI products, including VMWare’s View Manager and Citrix’s XenDesktop, enabling administrators to deploy virtual desktops alongside the SA series of SSL VPN devices. This allows the SA administrator to configure centralized remote access policies for users who access their virtual desktops.

• This provides a centralized point of configuration for administrators to configure remote access policies for virtual desktop access through leading virtualization products from VMWare and Citrix.
• SA 6.5 provides end users the VDI client to access the virtual desktop through, and provides flexible client fallback options thereby simplifying the deployment and management for administrators.

We have a lot of folks looking to access their corporate desktops remotely and the RDP (Terminal Services) feature of the Juniper SSL VPN really helps fill that role.

Cheers!

References;

What’s New in Juniper Networks Secure Access (SA) SSL VPN Version 6.5
Juniper Secure Access 6.5 Release Notes
WSAM and Network Connect Error Messages Release 6.5
Juniper Secure Access 6.5 Support Platforms

Update: Thursday November 5, 2009

Let me get right to the point, I would not recommend anyone deploy 6.5R1 on their Juniper Secure Access appliances. There are known issues with the Juniper Windows Secure Application Manager (WSAM) and the following four security suites; Norton 360, Symantec AntiVirus, Zone Alarm Security, ESET NOD32. Users with Norton 360 could experience a blue screen of death (BSOD) using the Juniper Windows Secure Application Manager. Juniper has a hotfix available for 6.5R1 that resolves the BSOD issues with Norton 360. The hotfix is not generally available on the Juniper website so you must contact JTAC for the hotfix.

Additional information can be found at this post; http://blog.michaelfmcnamara.com/2009/10/norton-360-and-juniper-ssl-vpn-wsam/

Update: Friday September 19, 2009

A quick update… I’ve setup a spare SA4000 and received a demo license from Juniper to test the 6.5R1 software release (thanks Matt!). I’m happy to report that the upgrade on the appliance was very smooth although it took about 6 minutes for the appliance to boot back up giving me a few frightful thoughts. Unfortunately the same can’t be said of the client software. I’m still in the process of testing but it appears that non-Administrator users (users that don’t have Administrator rights on the PC) won’t be functional after the upgrade until an Administrator manually installs the latest and greatest Juniper Installer Service. The Juniper Installer Service is designed to allow the client software to upgrade when the user doesn’t have Administrator rights. Users with Administrator rights work fine so long as they answer the prompts to install the new version of the Juniper Installer Service. I hope to release a detailed post in the next few days including some testing of Windows Vista 64-bit desktops.

Juniper has released software 6.5 for the Juniper SSL VPN (Secure Access) appliances which now supports running WSAM on Windows 64-bit operating systems. I’ve posted a new article that details the new software which can be found here; http://blog.michaelfmcnamara.com/2009/09/juniper-ssl-vpn-secure-access-6-5-available/

Almost six years ago we deployed a Neoteris Secure Access 1000 appliance which was designed to publish Intranet based web applications to Internet clients. Neoteris was acquired by Netscreen and then Netscreen was acquired by Juniper. Over a year ago we upgraded our legacy hardware with two Juniper SA4000s running them as a cluster in a high availability design (active/standby). The solution has been very successful with the exception of the occasionally home PC that for one reason or another refuses to install the client software.

We recently upgraded to software release v6.2R1 which promised full support for Windows Vista 64-Bit and Juniper’s Windows Secure Application Manager (WSAM). Juniper’s Windows Secure Application Manager is essentially a mini VPN client that tunnels traffic across an SSL connection with the SA4000 appliances. It provides raw connectivity for non-HTTP based applications. While the documentation indicated that Windows Vista 64-Bit was fully supported we were unable to make it work after a few customers reported having issues. We opened a ticket with Juniper and waiting four business days before Juniper was able to confirm our findings; they too were unable to make it work. We were informed the ticket was to be escalated to design but I immediately found it odd that no one else had already reported this problem. In short Juniper informed us that Windows Vista 64-Bit is not supported and the documentation indicating it was support was “incorrect”. Needless to say I’m not very happy with Juniper as this point and it certainly seems that Juniper has some serious QA issues in their software and documentation teams.  Let’s not even talk about the 9 business day turnaround which is essentially two weeks.

I recently had a discussion with a physician, remember I work for a large healthcare provider, who had tried in vein to help himself by Googling for any hints or tips to getting WSAM working with Windows Vista 64-Bit. So here are some tips that will hopefully get picked up by Google.

1. You must be an Administrator to install the software components
2. You’ll need to be running Windows XP (32-Bit) Service Pack 2 or later
3. If you have a pop-up blocker enabled make sure you exempt the Juniper URL
4. If you have your firewall enabled make sure you unblock WSAM

I’ve also seen issues if ActiveX, JavaScript, or Cookies are disabled from within Internet Explorer. The WSAM software is a Layered Service Provider (LSP) application and as such other software, malware, spyware, etc can sometimes interfere with it’s proper operation. You can have a look here for a utility that might help to clean up any LSP issues that you might have.

The Windows Secure Application Manager can not be run from within a Windows Terminal Server or Citrix session.

Cheers!

Update: August 13, 2008
I recieved a few questions about Juniper’s Windows Secure Application Manager (WSAM) and I thought I would pass on the questions and answers.

Q. Does Juniper’s WSAM support a proxy server?
A. No Juniper’s WSAM does not support a proxy server. The client will need direct Internet access on TCP 443 (https).

Q. Where are the log files, there’s nothing in C:\Program Files\Juniper Networks\Secure Application Manager?
A. The log file is actually stored in the following location; C:\Documents and Settings\<username>\Application Data\Juniper Networks\Secure Application Manager

Update: September 18, 2008
As noted in the comments Juniper has released a customer bulletin concerning the problem. Here’s the official response I received from the Juniper TAC, I haven’t received any follow-up from the sales team which the Juniper TAC referred me to.

“KB12097 was posted to our Knowledge Base Support site and engineering has implemented a check in the WSAM installation that will display an error to the user if they are attempting to install WSAM on a 64-bit Operating System. This fix should be available in the next maintenance release of IVE OS 6.2. As for future support for WSAM on 64-bit systems, this has been revisited by PLM and it is now on our roadmap.”

Update: October 5, 2008
I’m amazed at the number of views that this post has garnered. It seems there are quite a few folks out there trying to figure out why Windows Vista 64bit won’t work with WSAM. I thought I should point out that the Juniper Network Connect client is compatible with Windows Vista 64bit (and 32bit). This may be an option for users although those users will need to speak to their System Administrators since it will require additional configuration and perhaps even licensing.

Cheers!