Tag Archives: ssl

Automatically Renew SSL Cert with LetsEncrypt and getssl

Leave a reply
Let's Encrypt Logo

With the recent federal government shutdown, it’s quite apparent their IT administrators still renew SSL certificates manually since many government websites went offline after the certs expired. Politics aside, since having secured connection and valid certificates are important these days, it should be a point for administrators to start automating the process. At the very least, have a project or plan in place to anticipate the shutdown and go through all of the important websites for possible cert renewals, 1-2 months in advance. As an Enterprise administrator, it’s also essential to have alerts or calendar reminders to renew an expiring cert. However, the best solution is to setup an automated job.

This is where tools out there like getssl and certbot can help. For this website, getssl is used to automate the SSL renewal process. The key processes are as follows:

Ensure Apache web server is setup. Since getssl relies on obtaining the proper “ACME” code from the target website to confirm the correct URL host, a regular port 80 HTTP connection must be made available first.

Per getssl documentation, run the inital setup to create the proper folders and files in $HOME/.getssl

getssl -c yourdomain.com

Edit the getssl.cfg in $HOME/.getssl/yourdomain.com folder with the correct directory for Apache web server’s doc-root and configuration files. Note, package installed Apache HTTPD uses /etc/apache2 as the default config directory.

When getssl is all setup, create a crontab to run getssl twice every month, for timely renewal (within 30 days). Be sure to restart Apache HTTPD to make sure the web server reloads the latest cert files.

0 9 1,15 * * $HOME/getssl/getssl -u -a > $HOME/getssl/getssl.out.txt 2>&1

Heartbleed: A Scrambled Egg with Lots of Ham

Leave a reply

CVE-2014-0160The sensational headline news this week was “Heartbleed” security flaw, which was covered by most mainstream and tech sites.  It was an old bug that was accidentally introduced, and just discovered recently ((Introduced in 2011 and found out in February 2014)). The report got IT professionals scrambling to fix their systems.

At first glance, the bug is benign enough, with chances of hacking the passwords or SSL keys rather slim. However, like any other hacking issues, if someone is determined (and clever) enough to exploit this bug, they may just get a bunch of useful data. Whether or not they can use the hacked data to steal client information, or use it for a phishing site, it’s unclear. Just the thought of the potential leak scares the daylights out of everyone! It’s also proof that the marketing behind this bug was very effective.

Regardless, the actions need to be taken are as follows:

  1. Check with Qualys SSL Analyzer to determine if your site is vulnerable.
  2. If vulnerable, upgrade OpenSSL to version 1.0.1g, or alternatively recompile OpenSSL without the “heartbeat” option (-DOPENSSL_NO_HEARTBEATS).
  3. Recompile or restart the web server to reload the latest OpenSSL libraries.
  4. Test the site(s) with the Qualys SSL Analyzer again.  Also check if site is functional.
  5. With the new OpenSSL, generate a new SSL key, and re-key a new certificate.  Install the new key/certificate in the web server(s).
  6. Urge the users to change their passwords – which they occasionally have to do, anyway.  This step is tricky considering the PR scare that it’s going to generate when admitting the site is vulnerable.  However, the notification is the responsible thing to do.

When the dust settles, we can look back and use this as an important reminder how fragile the Internet is.  Customers are expected to be cautious of their data being transmitted over the Internet, no matter how secure a company claim they’re being kept.

SSL From Java Client

Leave a reply

java_sslI’ve described a way to install a self-signing SSL certificate using OpenSSL for testing purposes.  When connecting to a web server using a web browser client, it is straight forward to add the “fake” certificate (just follow the instructions on the browser screen).  However, in a Java application, it’s a little bit more work.

The procedure is the following:

  • Obtain the SSL certificate from the website administrator.  Alternatively, use the browser:
  1. Browse the URL, for example:  https://www.testmachine.com
  2. When the security window popup appears, just click ‘continue’.
  3. The browser has an option to view the certificate.  With Internet Explorer 7, next to the Address Bar there’s a “Certificate Error” button.  Press that and view certificate.  With Firefox, click on the yellow lock at the bottom of the screen.
  4. Go to the Details tab.
  5. Click on “Copy to File”.  In Firefox, click on the “Export” button.
  6. Save the file as “website.cert”
  • Copy the Cert file to where the Java client is going to be executed.
  • Go to the JRE (Java Run Time) library under lib/security, for example: /usr/local/jdk_1.4.3/jre/lib/security/
  • The certs are stored in a file called “cacerts”.
  • Run the keytool app to import the “website.cert” file that was exported earlier from a web browser:

keytool -import -alias websiteAlias -keystore cacerts -file website.cert

  • Enter the default password: changeit
  • Check the content of the new “cacerts” file using:

keytool -list -keystore cacerts

  • Test it.   If it’s a web container (i.e. Tomcat), restart the JVM.

Webapper site has a short Java client test code, and a quick procedure to compile/run a client to test it.