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

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.

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

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.

OpenSSL CA to sign CSR with SHA256 – Create CA

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.

Enable certificate based logon – 2 Maintain Client PSE of Web Dispatcher

OK, now it will get complicated. Certificate based logons do not really like reverse proxies. First step is to ensure that the client has a certificate that is accepted by the SAP NetWeaver ABAP PSE. For this, the certificate must be signed by a CA that the ABAP PSE trusts.

Log on the WD admin and select PSE Management

Select Recreate PSE.

In the DN field, use the name of the WD: CN=wd.tobias.de. The other information is optional, but should be added.

Right now, the certificate is created and the PSE has a private key, but the certificate is self-signed. To have an official certificate, it must be signed by a CA. To do this, select: “Create a CA Request” to create a CSR that will be send to the CA.

Create CA Request

Save the output in a TXT file, send it to your CA, let it get signed. Then, go back to WD admin and import the CA response.

The client PSE updates the issuer information. Now there must be shown the DN of the CA. In my case: C=BR, O=EJBCA, CN=ca.tobias.de

Configure MSFT NDES to work with Afaria

Afaria mobile client can request a client certificate from a corporate CA for the user. This means that the user will get automatically a valid certificate made available for him, without having to go through the complicated process of requesting and installing a certificate. The user won`t even know that a certificate was requested and installed on the device, it`s really a transparent process. For this to work, Afaria needs to be configured to send requests to a CA (using SCEP). The CA needs to be able to act on device requests. This is done by installing the type NDES to a Windows CA. After that, the CA needs to be configured to work together with Afaria.

A possible error message that can occur when this configuration is not done is visible in the Afaria log. The error message will look like: “SCEPcertificateAcquisition Exception: ASN1 bad tag value met

This error message won`t occur out of nothing, it is in the context of the Afaria client requesting a certificate at Microsoft CA/NDES.

Here, a CSR with Subject CN=rds,O=Afaria,OU=Consulting,L=Rio de Janeiro … was sent to the CA by the Android app com.sap.logon.cert. The solution for this problem is given by SAP Note 2193313. The documentation that treats this error can be obtained either from SAP or from Microsoft:

SOLUTION

Basically there are two solutions available:

  1. Deactive the use of a password for NDES or
  2. Activate the use of a password and configure Afaria to send the credentials

Easiest solution: deactivate usage of password when requesting a certificate. This is done by changing a Windows registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MSCEP\EnforcePassword to 0

This change requires a restart of IIS to ensure that the new value is picked up. Afterwards, the Afaria cliente can be used to request a certificate.

This request can be followed in the Afaria log:

RESULT

The client received a certifcate. The certificate can be seen in the CA:

Afaria Setup 6: Configure SSL for IIS

To ensure confidentiality of user data, access to SAP Afaria by users needs to be done using SSL. For this to work, IIS must use its own valid SSL certificate. To do so, first a certificate request for IIS must be created. This request will be handled by the CA (installed on same server) and the created certificate must be made available in IIS.

IIS: Create certificate request

  • Start IIS Manager
  • Select default server and sever certificates in IIS section.

  • Create certificate request

  • Inform server information. The CA will include this information in the final certificate.
    • Common name: FQDN of the server
    • Country: BR, or your country

  • Select cryptographic service provider.
    • Cryptographic service provider: Microsoft RSA SChannel Cryptographic Provider
    • Bit length: 1024

  • Inform file name. This is where the certificate request will be saved to. This file will be later submitted to the CA.

Now the certificate request is done by IIS. Next step is to submit the request to the CA.

CA: Issue certificate

As the CA is on the same server as IIS, it is only to submit the request to the CA. The certificate type is for a web server. In my case, using the CA wizard to submit the CSR did not work, as the web server template was not available. What worked was to use the command line to submit the CSR and inform there the web server template.

Command: certreq.exe –submit –attrib “CertificateTemplate:WebServer” .\certreq.txt

Select the CA to be used.

Specify path to save certificate to.

Certificate is issued and saved in CER format.

Next is to install the certificate into IIS and make it available for usage.

IIS: Install certificate

To install the server certificate, open IIS Manager console. Select Complete Certificate Request.

Inform the path to the certificate and na alias/friendly name. You’ll refer by friendly name to the certificate.

Click OK. This installs the certificate into IIS.