OpenSSL CA to sign CSR with SHA256 – Sign CSR issued with SHA-256

Let the world know ...Tweet about this on TwitterShare on Google+Share on FacebookEmail this to someoneShare on LinkedIn

The overall process is:

  1. Create CA
    1. Private CA key
      1. Create private key
      2. Check private key
    2. Public CA certificate
      1. Create public certificate
      2. Check public certificate
  2. Sign CSR
    1. SHA-1
      1. Create CSR using SHA-1
      2. Check CSR
      3. Sign CSR enforcing SHA-256
      4. Check signed certificate
    2. SHA-256
      1. Create CSR using SHA-256
      2. Check CSR
      3. Sign CSR
      4. Check signed certificate

Sign CSR request – SHA-256

When a CSR is created a signature algorithm can be specified. Currently, this should be SHA-256. Installing a TLS certificate that is using SHA-256 ensures that browsers like Chrome, Firefox, etc won`t show a security warning to the user. Signing the CSR using the CA is straight forward.

Create CSR using SHA-256

openssl req -out sha256.csr -new -newkey rsa:2048 -nodes -keyout sha256.key –sha256

The command creates two files: sha256.key containing the private key and sha256.csr containing the certificate request.

Check CSR

openssl req -verify -in sha256.csr -text -noout

The signature algorithm of the CSR is SHA-256

Sign CSR

Singing the CSR using the CA

openssl x509 -req -days 360 -in sha256.csr -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -out sha256.crt

This will sign the CSR using SHA-256 as provided by CSR.

Check signed certificate

openssl x509 -text -noout -in sha256.crt

The certificate is signed using SHA-256.

 

 

 


Possible problem: the certificate may be signed using SHA-1.

Why is the certificate signed with SHA1? Without providing –sha256 parameter, openssl is using the default value. Depending on the version of openssl you are using, the default may be using SHA-1. This is the case when you use the default openssl binary available on MacOs.

openssl version –a

This version is old. Better to install a newer one using brew.

After updating, the default algorithm is SHA-256 and not SHA-1 anymore. In case you cannot update the default openssl binary, install a newer version to a different location and use that one.

Let the world know ...Tweet about this on TwitterShare on Google+Share on FacebookEmail this to someoneShare on LinkedIn

OpenSSL CA to sign CSR with SHA256 – Sign CSR issued with SHA-1

Let the world know ...Tweet about this on TwitterShare on Google+Share on FacebookEmail this to someoneShare on LinkedIn

The overall process is:

  1. Create CA
    1. Private CA key
      1. Create private key
      2. Check private key
    2. Public CA certificate
      1. Create public certificate
      2. Check public certificate
  2. Sign CSR
    1. SHA-1
      1. Create CSR using SHA-1
      2. Check CSR
      3. Sign CSR enforcing SHA-256
      4. Check signed certificate
    2. SHA-256
      1. Create CSR using SHA-256
      2. Check CSR
      3. Sign CSR
      4. Check signed certificate

Sign CSR request – SHA-1

When a CSR is created, a signature algorithm is used. Normally, this is SHA-1. Installing a TLS certificate that is using SHA-1 will give some problems, as SHA-1 is not considered secure enough by Google, Mozilla, and other vendors. Therefore, the final certificate needs to be signed using SHA-256. In case the CSR is only available with SHA-1, the CA can be used to sign CSR requests and enforce a different algorithm.

Create CSR using SHA-1

openssl req -out sha1.csr -new -newkey rsa:2048 -nodes -keyout sha1.key

The command creates two files: sha1.key containing the private key and sha1.csr containing the certificate request.

Check CSR

openssl req -verify -in sha1.csr -text -noout

The signature algorithm of the CSR is SHA-1

Sign CSR enforcing SHA-256

Singing the CSR using the CA

openssl x509 -req -days 360 -in sha1.csr -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -out sha1.crt -sha256

This will sign the CSR using SHA-256.

Check signed certificate

openssl x509 -text -noout -in sha1.crt

The certificate`s signature algorithm is using SHA-256. The original CSR`s signature algorithm was SHA-1, but the resulting algorithm is now SHA-256. Even when you cannot change to SHA-256 during CSR creation, or the CSR is only available in SHA-1, it is still possible to change the SHA-256 during the signing process of the CA.

Let the world know ...Tweet about this on TwitterShare on Google+Share on FacebookEmail this to someoneShare on LinkedIn

OpenSSL CA to sign CSR with SHA256 – Create CA

Let the world know ...Tweet about this on TwitterShare on Google+Share on FacebookEmail this to someoneShare on LinkedIn

The overall process is:

  1. Create CA
    1. Private CA key
      1. Create private key
      2. Check private key
    2. Public CA certificate
      1. Create public certificate
      2. Check public certificate
  2. Sign CSR
    1. SHA-1
      1. Create CSR using SHA-1
      2. Check CSR
      3. Sign CSR enforcing SHA-256
      4. Check signed certificate
    2. SHA-256
      1. Create CSR using SHA-256
      2. Check CSR
      3. Sign CSR
      4. Check signed certificate

Create a CA

To have a private CA with openssl, at least two steps are need: you need to create a private key and a public certificate. The public certificate will be used to sign CSRs.

Private CA key

Create private key

openssl genrsa -aes256 -out ca.key.pem 4096

The command will generate a private key using random data and ask you to provide a pass phrase. While possible to enter an empty pass phrase, it is highly recommended to provide one. In my test case, I simply use “test”. Remember: it is not a password, but a phrase. If you want, go crazy and use a full sentence.

Check private key

This creates a pass phrase protected private key. The key is password protected. This can easily be seen by opening the key and checking for the —–BEGIN RSA PRIVATE KEY—– section.

To validate that everything is OK with the private key, openssl can be used

openssl rsa –in ca.key.pem -check

The output prints RSA key ok.

Public CA certificate

Create public certificate

openssl req -key ca.key.pem -new -x509 -days 5000 -sha256 -extensions v3_ca -out ca.cert.pem

You`ll need to inform the pass phrase of the private key as well as some additional administrational data like the location of the server.

This created a new certificate for the CA using the private key.

Check public certificate

openssl x509 -in ca.cert.pem -text -noout

The Signature Algoritm is using SHA-256.

Using the above two commands, a private key and public certificate with usage type for CA was created. This certificate can now be used to sign CSR requests.

Let the world know ...Tweet about this on TwitterShare on Google+Share on FacebookEmail this to someoneShare on LinkedIn

OCSP part 6 – Test OCSP service

Let the world know ...Tweet about this on TwitterShare on Google+Share on FacebookEmail this to someoneShare on LinkedIn

To test if OCSP is working, you need to have a certificate with OCSP information included. This is only available for certificates emitted AFTER the service was installed, configured and activated on the CA. Therefore, you`ll need to first create a new certificate for your tests. Depending on your CA configuration, you can use OpenSSL to create a request or will have to use the Windows integrated tools. I will show here how to use a CSR created by OpenSSL and a Windows Enterprise CA.

Create CSR with OpenSSL

openssl req –new –newkey rsa:2046 –nodes –keyout dummy.key –out dummy.csr

This creates a key file and the CSR in Base64.

Submit CSR to CA

Certificate snap-in

MSFT Enterprise CA needs the CSR created for a specific template, something that OpenSSL is not offering. If you submit such a request to the CA via MMC, you get an error message.

More information

CA Web Interface

Open the web enrollment server in your browser. Click on Request a certificate.

Go to the advanced options.

Paste the Base64 encoded CSR in the input field. Select as certificate User.

Submit the request and download the generated certificate.

Take a closer look at the certificate. In the AIA section, OCSP must be shown.

Test OCSP service

In the above step, a new user certificate was created, containing OCSP information. To test if OCSP is working, Microsoft is offering the certutil tool.

certutiil –URL dummy.cer

In the Retrieve box, you can select how to certificate information should be retrieved.

Select OCSP.

Check the status

Result: Failed

Result: Unsuccessful

Result: Verified

Let the world know ...Tweet about this on TwitterShare on Google+Share on FacebookEmail this to someoneShare on LinkedIn

Verify certificate chain with OpenSSL

Let the world know ...Tweet about this on TwitterShare on Google+Share on FacebookEmail this to someoneShare on LinkedIn

A good TLS setup includes providing a complete certificate chain to your clients. This means that your web server is sending out all certificates needed to validate its certificate, except the root certificate. This is best practice and helps you achieving a good rating from SSL Labs. In a normal situation, your server certificate is signed by an intermediate CA. With this, your complete certificate chain is composed of the Root CA, intermediate CA and server certificate.

You do get signed your certificate by an intermediate CA and not the Root CA, because the Root CA is normally an offline CA. As the name suggests, the server is offline, and is not capable of signing certificates. Its certificate is included into the build-in root CA list of clients (browsers).The intermediate CA is online, and it`s task is to sign certificates. Compared to the root CA, its own certificate is not included in the built-in list of certificates of clients. Of course, the web server certificate is also not part of this list. For a client to verify the certificate chain, all involved certificates must be verified. Server certificate by intermediate CA, which is verified by Root CA. Client already has the root CA certificate, and at least gets the server certificate. Missing certificate therefore is the one of the intermediate CA.

When a client connects to your server, it gets back at least the server certificate. To validate this certificate, the client must have the intermediate CA. For this, he will have to download it from the CA server. The root CA is pre-installed and can be used to validate the intermediate CA. Well, it should download. But not all server certificates include the necessary information, or the client cannot download the missing certificate (hello firewall!). In that case, it is not possible to validate the server`s certificate. Therefore the server should include the intermediate CA in the response.

Now the client has all the certificates at hand to validate the server. In case more than one intermediate CAs are involved, all the certificates must be included. The chain is N-1, where N = numbers of CAs.

Verify certificate chain with OpenSSL

Enough theory, let`s apply this IRL. Use OpenSSL to connect to a HTTPS server (using my very own one here in the example).

openssl.exe s_client -connect www.itsfullofstars.de:443

Output

Loading 'screen' into random state - done
CONNECTED(000001EC)
depth=1 C = IL, O = StartCom Ltd., OU = StartCom Certification Authority, CN = StartCom Class 1 DV Server CA
verify error:num=20:unable to get local issuer certificate
---
Certificate chain
0 s:/CN=www.itsfullofstars.de
i:/C=IL/O=StartCom Ltd./OU=StartCom Certification Authority/CN=StartCom Class1 DV Server CA
1 s:/C=IL/O=StartCom Ltd./OU=StartCom Certification Authority/CN=StartCom Class1 DV Server CA
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGJjCCBQ6gAwIBAgIQEH6ZTKIfC5k6iN7ERWeE9zANBgkqhkiG9w0BAQsFADB4sH+ryHeVQVMe4WxKH2nUKbTtE0ppeCQqXL1ExXXDCD1jANVy0pjlVNHbJJJq9voViyYWxhBveiaEJ02N/gOfgkawwIhYiE3Ur6DLlJh0ynXVuXSsRrV5zCI0
-----END CERTIFICATE-----
subject=/CN=www.itsfullofstars.de
issuer=/C=IL/O=StartCom Ltd./OU=StartCom Certification Authority/CN=StartCom Class 1 DV Server CA
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 4041 bytes and written 443 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 2D5[…]2F0
Session-ID-ctx: Master-Key: 9D8[…]DCF
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 3d 21 23 92 67 cc 97 a5-17 c5 09 9e 69 da ea 6d =!#.g.......i..m[…]
00b0 - ac fb 79 22 fc c6 fa 9b-ef c8 0e cb 6c 27 72 83 ..y"........l'r.
Start Time: 1455216192
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---

If you cannot interpret the result: it failed. Verify return code:20 means that openssl is not able to validate the certificate chain. The certificate chain can be seen here:

  • 0: the certificate of the server
  • 1: the certificate of the CA that signed the servers certificate (0)
  • s: is the name of the server, while I is the name of the signing CA. To get a clearer understanding of the chain, take a look at how this is presented in Chrome:

The certificates send by my server include its own and the StartCom Class 1 DV Server CA.

Server certificate:

StartCom Class 1 DV Server CA

Missing: Root CA: StartCom Certificate Authority. This is the Root CA and already available in a browser. It`s not available in OpenSSL, as the tool comes without a list of trusted CAs. To “install” the root CA as trusted, OpenSSL offers two paramters:

  • CAfile. Point to a single certificate that is used as trusted Root CA
  • CApath. Point to a directory with certificates going to be used as trusted Root CAs.

I will use the CAfile parameter. For this, I`ll have to download the CA certificate from StartSSL (or via Chrome).

openssl.exe s_client -connect www.itsfullofstars.de:443 -CAfile startssl_rootca.cer

Output

Loading 'screen' into random state - done
CONNECTED(000001EC)
depth=2 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN =StartCom Certification Authority
verify return:1
depth=1 C = IL, O = StartCom Ltd., OU = StartCom Certification Authority, CN = StartCom Class 1 DV Server CA
verify return:1
depth=0 CN = www.itsfullofstars.de
verify return:1
---
Certificate chain
0 s:/CN=www.itsfullofstars.de
i:/C=IL/O=StartCom Ltd./OU=StartCom Certification Authority/CN=StartCom Class1 DV Server CA
1 s:/C=IL/O=StartCom Ltd./OU=StartCom Certification Authority/CN=StartCom Class1 DV Server CA
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGJjCCBQ6gAwIBAgIQEH6ZTKIfC5k6iN7ERWeE9zANBgkqhkiG9w0BAQsFADB4sH+ryHeVQVMe4WxKH2nUKbTtE0ppeCQqXL1ExXXDCD1jANVy0pjlVNHbJJJq9voViyYWxhBveiaEJ02N/gOfgkawwIhYiE3Ur6DLlJh0ynXVuXSsRrV5zCI0
-----END CERTIFICATE-----
subject=/CN=www.itsfullofstars.de
issuer=/C=IL/O=StartCom Ltd./OU=StartCom Certification Authority/CN=StartCom Class 1 DV Server CA
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 4041 bytes and written 443 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 9[…]43
Session-ID-ctx: Master-Key: 4C[…]2D
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 3d 21 23 92 67 cc 97 a5-17 c5 09 9e 69 da ea 6d =!#.g.......i..m
0010 - fc 05 be 96 ce bd 98 d6-d0 80 f9 67 1c 09 8c 4a ...........g...J
00b0 - 3a c2 73 77 e3 40 ab 22-84 1b f2 6a 5a 4a 8e 68 :.sw.@."...jZJ.h
Start Time: 1455217879
Timeout : 300 (sec)
Verify return code: 0 (ok)
---

Return code is 0. Now it worked. OpenSSL was able to validate all certificates and the certificate chain is working.

More resources

https://community.qualys.com/docs/DOC-1931

https://www.openssl.org/docs/manmaster/apps/verify.html

Let the world know ...Tweet about this on TwitterShare on Google+Share on FacebookEmail this to someoneShare on LinkedIn