Categories
Other

How to: request a CSR with OpenSSL

There are many ways to request a CSR. You can do this in the certificate store on your device (with MMC) or IIS. The possibilities are almost endless. In this post I going to explain what I’m using and what I think that is the easiest way.

Why I use OpenSSL

As the title say, I use OpenSSL for requesting CSRs. I always prefer IIS back in time, but since I know this gives you a sha1 cryptographic hash and IIS cannot be used if you are requesting a SAN (multi- domain SSL).

So I first switched to using the MMC console, but I found the way to archive a SAN with sha256 cryptographic is to much work. That’s why I started looking at the possibilities of OpenSSL and I think it’s the best tool to use!

How I use OpenSSL

OpenSSL is available for most Unix-like operating systems. In earlier blogs I told that I’m using a local Debian VM, but in this situation I’m running Windows Subsystem for Linux (WSL) or on my Mac directly within the Terminal.

Let’s start with obtaining a CSR

This blog will use the /tmp folder. If you are you using WSL the temp folder is located in (if you use Ubunutu):

\\wsl$\Ubuntu\tmp.

1: Create a file in /tmp called ‘req.cnf’ and copy the following information.

For requesting a single or wildcard domain certificate, paste the following into the ‘req.cnf’ file.

[req]
default_bits = 2048
distinguished_name = req_distinguished_name
req_extensions = v3_req
[req_distinguished_name]
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name (full name)
localityName = Locality Name (eg, city)
organizationName = Organization Name (eg, company)
organizationalUnitName = Organizational Unit Name (eg, section)
commonName = Common Name (e.g. server FQDN or YOUR name)
[v3_req]
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectKeyIdentifier = hash
basicConstraints = critical, CA:false

For requesting a SAN (Subject Alternative Names) certificate, paste the following into the ‘req.cnf’ file. Only change the DNS names to your needs, more then three? Just add DNS.4 = yourdomain.com to the list.

[req]
default_bits = 2048
distinguished_name = req_distinguished_name
req_extensions = v3_req
[req_distinguished_name]
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name (full name)
localityName = Locality Name (eg, city)
organizationName = Organization Name (eg, company)
organizationalUnitName = Organizational Unit Name (eg, section)
commonName = Common Name (e.g. server FQDN or YOUR name)
[v3_req]
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectKeyIdentifier = hash
basicConstraints = critical, CA:false
subjectAltName = @alt_names
[alt_names]
DNS.1 = www.vand3rlinden.nl
DNS.2 = mail.vand3rlinden.nl
DNS.3 = ricardo.vand3rlinden.nl

2: When the file is saved run the below command, this will create the CSR with the corresponding private key, that we need later.

openssl req -out /tmp/company.csr -newkey rsa:2048 -nodes -sha256 -keyout /tmp/private.key -config /tmp/req.cnf

You will be requested to fill your information, commonName will be your main domain.

3: Verify the CSR

Verify subject information:

openssl req -text -noout -verify -in /tmp/company.csr | grep Subject:

Verify if SAN DNS names:

openssl req -text -noout -verify -in /tmp/company.csr | grep DNS

4: Upload the CSR at a trusted Certificate Authority (CA)

5: When you get back the signed public key from your CA in .crt or .cer format, place this into the /tmp folder.

6: Download the Root and Intermediate certificate and then copy the content of the root and intermediate certificate in the main certificate, do this in the following order:

-----BEGIN CERTIFICATE-----
MAIN CERTIFICATE
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
INTERMEDIATE CERTIFICATE
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
ROOT CERTIFICATE
-----END CERTIFICATE-----

7: Now we are combine the public key from step 5 with the private key from step 2, to a .pfx bundle file (if PKCS #12 format is requested).

openssl pkcs12 -inkey /tmp/private.key -in /tmp/cert.cer -export -out /tmp/your-domain-com.pfx

You will be asking to give the .pfx file a password.

8: The certificate is now ready for use. If you combined the public and private key to .pfx, then you could check if the certificate chain is in the correct order as in step 6:

openssl pkcs12 -info -in /tmp/yourpfx.pfx

In addition:

I always check after uploading a certificate, if the certificate has no chain issues in the service you uploaded it. You can check this on ssllabs.com, put in your hostname and look under ‘chain issues’.

I once encountered an issue in an Azure Application Gateway where the root certificate was already in the service his trust store, after removing the root certificate from the certificate chain as in step 6, the chain issue was solved.

Some services may let you upload a CA bundle certificate (intermediate + root only), then you don’t need to combine the full chain as in step 6.


Share this: