Fixing SSL errors on Android Chrome with RapidSSL

Your ‘Order: xxxxxxx Complete’ email from RapidSSL includes links to a bunch of intermediate SSL certificates. Will you install the right one? I have seen installing the incorrect intermediate SSL certificate into the certificate chain cause Chrome on Android to declare a site insecure and block users from accessing it, while every other browser accepts it.

This tool helped me fix the issue: https://ssltools.geotrust.com/checker/views/certCheck.jsp. It pointed out that the wrong intermediate certificate was in the chain, and directed me to download a RapidSSL SHA256 CA - G3 certificate. I chained that with my server’s SSL certificate, and my Android issue went away.

Links

Adobe AIR desktop apps, expiring signing certificates, and the developer

Is the app timestamped?

Here is the important bit about timestamping from Adobe’s ‘Digitally signing an AIR file’ documentation

When you sign an AIR file, the packaging tool queries the server of a timestamp authority to obtain an independently verifiable date and time of signing. The time stamp obtained is embedded in the AIR file. As long as the signing certificate is valid at the time of signing, the AIR file can be installed, even after the certificate has expired. On the other hand, if no time stamp is obtained, the AIR file ceases to be installable when the certificate expires or is revoked.

  1. Download the .air file
  2. Change extension to .zip
  3. Extract or browse the contents of the .zip file
  4. Open META-INF/signatures.xml
  5. Look for a SignatureTimeStamp element. If it is there, the AIR app is timestamped

The app I’m working with is timestamped, so it can be installed indefinitely. But what about updates?

Expired certificates and app updates

Here’s another important bit from Adobe’s documentation

As of AIR 1.5.3, a certificate that has expired within the last 180 days can still be used to apply a migration signature to an application update. To take advantage of this grace period, and the update application descriptor must specify 1.5.3 in the namespace attribute. After the grace period, the certificate can no longer be used. Users updating to a new version of your application will have to uninstall their existing version. Note that there is no grace period in AIR versions before 1.5.3.

If an app uses AIR 1.5.3 or newer, the developer has 180 days past certificate expiry date to migrate to a new certificate. Time to find expiry the date!

Checking when a signing certificate expires

Assuming you have access to the .p12 version of the certificate and the password, you can follow these instructions (based on these from BSD Support). You can use the CLI application openssl (comes with Linux and OS X, msysgit for Windows includes it) to complete these steps.

  1. Convert the .p12 to a .pem file
    openssl pkcs12 -in certificate.p12 -out tempcrt.pem

    You will also be asked to provide the .p12’s password, and a new password to secure the resulting .pem file.

  2. Check the expiry date of the .pem file

    openssl x509 -in tempcrt.pem -text

    This will output a few screens of information in your terminal, including valid dates for the certificate. Here’s what you are looking for:

    Validity
            Not Before: Jan  5 05:21:03 2009 GMT
            Not After : Jan  5 05:21:03 2029 GMT

How to react as the AIR app’s developer

Put the dates in your calendar

If the Not After date is waaay in the future, then relax.

If the Not After date is coming soon, start thinking about how to handle migrating your app to a new certificate.

If the Not After date has passed less than 180 days ago and your app uses AIR 1.5.3 or newer, it is time to migrate to a new certificate. If the app uses an older version of AIR, it is too late to migrate to a new certificate to allow for smooth updates.

If the Not After date is more than 180 days ago, migrating the application to a new certificate is not an option. Users will have to uninstall and re-install your application instead of updating it.