Category: tls-ssl

Convert a CRT SSL certificate chain to PFX format

   

Many SSL certificate authorities (CAs) do not natively support .PFX format certificates which means that if you plan on installing them on something like an Azure App Service, you may encounter issues. Today, let’s figure out how to convert a CRT SSL certificate chain to PFX format.

First, let’s generate a private key and certificate signing request. Run the following command, and answer the questions as accurately as possible. The private key file (domain.key) should be kept secret and protected.

openssl req \
        -newkey rsa:2048 -nodes -keyout domain.key \
        -out domain.csr

Next, take the contents of domain.csr (it is just a plaintext file with your answers and some other non-secret information base64-encoded; it can be opened in any text editor) and request your certificate through your CA. This process varies per certificate authority, and so is out of scope for this article.

[Time passes]

Now, your CA provides you with a .ZIP file with the following files.

your_domain_com.crt
AAACertificateServices.crt
DomainValidationSecureServerCA.crt
USERTrustRSAAAACA.crt

(where your_domain_com.crt is the actual certificate file and the other .CRT files represent the various certificates that will allow a browser to chain up to the root; while the filenames and number of files will almost certainly be different for each certificate authority, the point here is to illustrate that there will be some number of .CRT files and that they are all important)

Extract those files into the same folder that you have the domain.key file from earlier in.

Finally, let’s take our certificate and combine them with the rest of the chain to create a single .PFX file by running the following command. Your site’s certificate should be specified in the -in parameter, and for each of the chain certificates, adding another -certfile entry.

openssl pkcs12 -export -out certificate.pfx \
        -inkey domain.key \
        -in your_domain_com.crt \
        -certfile AAACertificateServices.crt \
        -certfile DomainValidationSecureServerCA.crt \
        -certfile USERTrustRSAAAACA.crt

NOTE: Azure App Services and Azure Key Vaults require a password-protected .PFX file, so ensure that you enter one when prompted. When you go to upload the certificate and you are required to select the .PFX file and a password, the password you created here is the one it’s referring to.

And you’re done! You now have a file in that folder (certificate.pfx) that you can upload/install and ensure your site is protected against MITM attacks.

macro shot of stainless steel padlock

Public key authentication for non-techies

   

Over the last couple weeks, I’ve had a number of conversations with people on our product and delivery teams about public key authentication due to conversations they’ve had to have with some of our vendors. After having to explain public key authentication to non-techies several times, I figured it might be useful to post something public in case it helps anyone else.

So what is public key authentication and how does it work?

At it’s base, public key authentication is a secure way for a user or client to connect to a service via SSH, without having to send a password across the wire. Passwords can be intercepted and so the fewer times we have to send a password across an untrusted network, the better. Before the first connection is ever established, the client generates a public/private key pair and then sends their public key to the server they wish to connect to, while keeping their private key private.

Now the math that goes into why sharing this public key in the open isn’t a problem is a bit complicated (but hardly goes beyond grade 12 math), but it’s a lot easier to understand when you compare it to a real world scenario.

Let’s say you have a friend (vendor) and they have a shed (server) that you want to access and leave a batch of freshly baked cookies (files) for on a regular basis when they’re not home. You think about it for a while and come up with a solution: “Friend, please install a separate door (username) on your shed that only provides access to a small section of it (your home folder)”. Next, you go to the hardware store and buy a deadbolt lock (public key) that comes with a metal key (private key) that you keep on your keychain. Finally, you send this deadbolt lock to your friend to install on the door, while never showing them the key that opens the lock.

You can now come and go as you please, leaving your friend freshly baked cookies every few days, and since your key never left your possession, you can be sure that one else is sneaking inside the shed to steal the cookies. Additionally, your friend never needs to see the key because they have access to the whole shed, and you can be certain that no one else will ever be able to open up the lock because they don’t have your key.

This is public key authentication in a nutshell.

One added benefit that I haven’t really touched on here is that public key authentication – when properly created and protected – is the securest way to offer access to a system. Due to the math involved, it would take an adversary many times longer than the entire universe’s existence (that is not an exaggeration) to break your private key. Basically you can assume that if you do it right, it’s going to be secure.

I hope this made public key authentication a little less confusing and daunting for the non-techies who read this site, but if not, Khan Academy has a great video that goes into more depth using paint and color mixing. And if that still doesn’t answer your question, please leave a comment and I’d be happy to go into more detail.

locks on grate wall

Cloudflare – Error 520: What is wrong and how to fix it?

  

We recently ran into an issue setting up a new DNS entry on Cloudflare, using the orange-cloud (reverse proxying) feature, but we were receiving Error 520 and were curious what was wrong and how to fix it.  The error page itself doesn’t give a lot of information and since it’s a custom error they’ve created, it wasn’t easy to find out or even intuit much information about what it might mean.

To give some backstory, we are using a SaaS provider of a service for our employees that we want to protect behind our own domain. For example, instead of using ourcompany.saascompany.com, we wanted to use something like saasservicename.ourcompany.com. The provider supported this and so we set up the record within Cloudflare but as soon as we tried to visit the page, we received Cloudflare’s infamous 520 error: “Web server is returning an unknown error”.

After trying to troubleshoot the problem through Cloudflare, we turned off the orange-cloud and figured out that the SaaS provider hadn’t installed our TLS certificate correctly and so when Cloudflare was attempting to retrieve our instance from their server, they were receiving the NET::ERR_CERT_COMMON_NAME_INVALID. In response to that, they were throwing their own custom error 520 (it is not an official error code).

As soon as the vendor fixed the certificate issue, the 520 went away and we were able to re-enable orange-cloud, confirm that the site was up and working, and continue on with life confident that an attacker would not be able to determine who is providing the SaaS service for us.