How to create a certificate using OpenSSL with Subject Alternative Name field (SAN)

<< Click to Display Table of Contents >>

Navigation:  Bizagi Studio > How To´s > Useful how-to's >

How to create a certificate using OpenSSL with Subject Alternative Name field (SAN)

Overview

Browsers have strengthened the security policies and require that web applications opened use secure protocols like HTTPS. Because Bizagi's Work Portal is accessed using web browsers you must set all your Work Portal environments using HTTPS.

 

What is SAN

The Subject Alternative Name lets specify host names, for example, sites (e.g. www.myapp.com), IP addresses, domains (e.g. *example.com) or common names protected by the same certificate.

 

Browsers that require HTTPS with SAN

•Chrome from version 58. It also requires that the certificate must have the Subject Alternative Name field (SAN).

•Edge

Note: Although other browsers might not ask for a certificate to use the HTTPS protocol, it is advisable to configure HTTPS for all your environments (development, test, and production).

 

Certificate for Development and Test environments

For the development or test environment, you can either used purchased certificates (if you already have), signed certificates by a CA, or you can use self-signed certificates. If you use self-signed certificates it is important that the certificate has the Subject Alternative Name field (SAN).

 

Certificate for Production environments

In production environments, you cannot use self-signed certificates. Therefore, you need to acquire a certificate from a Certifying Authority (CA).

 

Create Self-signed certificates

The following illustration represents (at a high level) working with certificates. The Certificate Authority may not necessarily be an external one but can be set up locally by use of a self-signed certificate.

 

x509_overview

 

The illustration shows generating a certificate using a private and a public key pair.  You sign the certificate with the root certificate of a Certificate Authority (providing the public key through a certificate signing request CSR). Then you issue and export the signed certificate in a P12 or PFX format.

 

Before you start

We recommend that you create a folder to store the certificates to be issued within the following steps, so you can locate them easily. This path to the folder will be referred to as <CERT_DIR>. You need writing permissions on the folder, so make sure you create it within a folder with permissions.

 

For this example we are going to use the following path C:\temp\MyCerts

 

Configuration Steps

In self-signed certificates the CA authority is yourself, therefore, the steps to create a self-signed certificate is follow these steps:

1. Download Open SSL

2. Create your own authority (become a CA)

3. Create a configuration file for the certificate

4. Create a certificate signing request (CSR) for the server

5. Sign the CSR with your CA key

6. Export the certificate to P12 format

7. Install the server certificate

8. Configure the web application server (IIS) using the certificate

9. Add the certificate to the server trusted store

 

1. Download OpenSSL

Download the appropriate installer of OpenSSL from https://slproweb.com/products/Win32OpenSSL.html, where you can choose 64-bit or 32-bit installers according to your system architecture, use the full installer.

 

For Windows OS, a wizard can help you install the SDK. Follow the default steps to copy OpenSSL DLLs to The OpenSSL binaries (bin) directory:

 

OpenSSL_2

 

After a successful installation in Windows, you should be able to see the openssl.exe executable file, along with its openssl.cfg configuration file, in the bin folder of the location you selected during installation.

 

We recommend that you add OpenSSL to your system environment variables so that you can run its executable without needing to worry about paths.

To do this, edit the Path variable:

 

SAML_OpenSSL2

 

Add the OpenSSL's bin folder into the registered locations:

 

SAML_OpenSSL1

 

Click OK to save your changes before closing any windows (opened command prompts, environment variable windows, etc).

The steps in this article use OpenSSL from a command prompt. To learn about other options and for complete information about OpenSSL, refer to its official documentation at https://www.openssl.org/docs/man1.0.2/apps/openssl-req.html.

 

2. Become a self-signing Certifying Authority (CA)

When a CA signs a certificate signing request, it uses its own private key for signing purposes. Therefore, to create your own CA key, you need to follow these steps:

 

Open a command prompt, change the directory to the <CERT_DIR>, and then execute this command:

 

openssl req -new -newkey rsa:2048 -days [validity] -extensions v3_ca -subj "[key_details]" -nodes -x509 -sha256 -set_serial 0 -keyout [root_key].key -out [root_cer].cer

 

where

[validity]: The number of days to certify the certificate for. For instance setting 365 makes the certificate valid for 1 year.

[key_details]: The identifier and displayed details of the certificate.

The information should follow the following format: /C=[CO]/ST=[ST]/L=[city]/O=[org]/OU=[unit]/CN=[display_name]/

Replace [CO] with your 2-digit country code, [ST] with your 2-digit state code, [city] with your locality or city, [org] with your organization's name, [unit] for the organizational unit, and [display_name] for the identifier of the certificate.

For clarity and convenience, we suggest that the [display_name] includes the word Root somewhere.

[root_key]: The name for the file which will be generated holding the private key.

For clarity purposes and for your own convenience, we suggest that the name includes the word Root somewhere.

[root_cer]: The name for the certificate file which will be generated with the public key.

For clarity purposes and for your own convenience, we suggest that the name includes the word Root somewhere.

 

SAML_OpenSSL21

 

3. Create a configuration file for the certificate with Subject Alternative Name

To create a Certificate using the Subject Alternative Name field you need to create an OpenSSL configuration file that allows creating certificates with this attribute.

 

Create a new folder or use a folder with writing permissions.

 

Create an empty text file. Name it openssl-san.cnf The cnf extention is important.

 

Add the following lines to the file.

 

[ req ]

default_bits           = 2048

distinguished_name     = req_distinguished_name

req_extensions         = req_ext

 

[ 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)

commonName             = Common Name (e.g. server FQDN or YOUR name)

 

# Optionally, specify some defaults.
countryName_default           = [Country]
stateOrProvinceName_default   = [State]
localityName_default           = [City]
0.organizationName_default     = [Organization]
organizationalUnitName_default = [Organization unit]
emailAddress_default           = [Email]

 

[ req_ext ]

subjectAltName = @alt_names

 

[alt_names]

DNS.1   = [DNS1]

DNS.2   = [DNS2]

 

Replace the following values:

[Country]: Country name (2 letter code).

[State]: State or Province name (full name).

[City]: City name (full name).

[Organization]: Name of your organization

[Organization unit]: Name of the organizational unit.

[Email]: Your email address.

[DNS1] or [DNS2] (or more if needed): you can write the DNS associated with the site of your Work Portal. If you are using localhost you can write multiple options for access it. For example, you can use the following options: "localhost","127.0.0.1","localhost.domain.com","*.domain.com".

 

See an example using the localhost DNS alternative names:

 

hmtoggle_plus1        Configuration File Example [ req ]
default_bits           = 2048
distinguished_name     = req_distinguished_name
req_extensions         = req_ext

[ 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)
commonName             = Common Name (e.g. server FQDN or YOUR name)

# Optionally, specify some defaults.
countryName_default            = US
stateOrProvinceName_default    = California
localityName_default           = San Francisco
0.organizationName_default     = My Company
organizationalUnitName_default = research
emailAddress_default           = me@mycompany.com

[ req_ext ]
subjectAltName = @alt_names

[alt_names]
DNS.1   = localhost
DNS.2   = 127.0.0.1
DNS.3
= localhost.mydomain.com
DNS.4
= *mydomain.com

 

Save the file in a location path you have writing permissions.

 

4. Create a Certificate Signing Request (CSR)

You need to issue a Certificate Signing Request before issuing a final certificate, while creating both a private key and a public key file.

 

Open a command prompt, change the directory to the <CERT_DIR>

 

Run the following command to create a Certificate Signing Request for the certificate to be used to sign assertions:

openssl req -newkey rsa:2048 -subj "[certificate_details]" -nodes -sha256 -keyout [key_name].key -out [csr_name].csr -config [ConfigFilePath]\openssl-san.cnf

 

Replacement:

[certificate_details]: The identifier and displayed details of the certificate.

Use the following format: /C=[CO]/ST=[ST]/L=[city]/O=[org]/OU=[unit]/CN=[display_name]/

Replace [CO] with your 2-digit country code, [ST] with your 2-digit state code, [city] with your locality or city, [org] with your organization's name, [unit] for the organizational unit, and [display_name] with your identifier of the certificate.

[key_name]: The name of the file holding the private key which will be generated.

[csr_name]: The name for the file holding the certificate signing request with the public key which will be generated.

[ConfigFilePath]: The folder where you saved the CNF file.

 

SAML_OpenSSL22

 

Once the command runs successfully, the two output files (.key and .csr) should appear in your <CERT_DIR> folder:

 

SAML_OpenSSL23

 

5. Sign the request

To sign the request, you need a Certificate Authority (CA), For self-signed certificates, you can sign the certificate using the CA key created previously. You can also send the CSR file to a public CA or a CA your organization can have.

 

Self-Signing using OpenSSL

If you are going to self-sign using your own CA key. Open a command prompt, change the directory to the <CERT_DIR>

 

Then execute the following command:

openssl x509 -req -sha256 -CAcreateserial -in [csr_name].csr -days [validity] -CA [root_cer].cer -CAkey [root_key].key -out [cer_name].cer
 

Where:

•[csr_name]: The name of the Certificate Signing Request file, as defined and generated in the previous step.

•[validity]: The number of days that the certificate is valid. Setting this to 365 makes it valid for  1  years. Some browsers do not accept certificates that are valid for more than two years, however you can decide what best suits your policies.

•[root_key]: The name of the file holding the private key of the Certificate Authority.

It should match the name you defined in the previous step if you generated a Certificate Authority; or the name of the file you copied into the <CERT_DIR> folder if you are using an existing one.

•[root_cer]: The name for the certificate file holding the public key of the Certificate Authority.

It should match the name you defined in the previous step if you generated a Certificate Authority; or the name of the file you copied into the <CERT_DIR> folder if you are using an existing one.

•[cer_name]: The name for the final certificate file which will be generated with the public key.

 

SAML_OpenSSL24

 

This generates a .cer file associated with your certificate in the<CERT_DIR> folder.

 

Signing using the windows command and your organization CA

Open a command prompt and browse into the <CERT_DIR> folder you created. Run the following command to sign the request CSR:

 

certreq -submit -attrib "CertificateTemplate:WebServer" [csr_name]

 

Where:

[csr_name]: The name of the Certificate Signing Request file defined here.

 

Select the CA, for this example we are using VisionSoftware (Kerberos) in the window displayed. Then, click OK.

 

SubjectAltName03

 

Save the file with .cer extension.

Once the command runs successfully, the output file with .cer extension appears in your <CERT_DIR> folder.

 

6. Export the private and public key under a P12 or PFX format

To install the certificate in the application server (IIS) You need a P12 or PFX file holding both the private and the public key.

 

Open a command prompt, change the directory to the <CERT_DIR> . Then run the following command:

 

openssl pkcs12 -export -in [cer_name].cer -inkey [key_name].key -CSP "Microsoft Enhanced RSA and AES Cryptographic Provider" -out [p12_name].p12

 

Consider replacing:

[cer_name]: The name of the certificate file you signed in the previous step.

[key_name]: The name for the private key file of the signed certificate.

[p12_name]: The name for the P12 file which will be generated.

 

SAML_OpenSSL25

 

At this point, you see a prompt to define and confirm a password for the P12 file.

Make sure you copy the password and that keep it in a safe place, as you need it for configuration steps later on in the server.

 

Once the command runs successfully, a .p12 output file should appear at your <CERT_DIR> folder.

 

Checkpoint

At this point you may choose to verify that the .p12 file is well-formed and has everything you need.

 

For this, run the following command to verify the .p12 file:

openssl pkcs12 -info -nodes -in [p12_name].p12

 

Customization:

[p12_name]: The name for the P12 file, you defined and generated.

 

At this point, you will see a prompt to enter the password for the P12 file you defined.

 

Apart from checking that there no errors in the command, you can verify:

That the password you defined is correct.

That a public and private key are displayed.

That the subject displays accurately the details you defined when generating the certificate.

That the issuer displays accurately the details of the Certificate Authority used to sign the certificate.

Other details, such as the employed algorithm.

 

7. Install the certificate

Follow the steps below to install the certificate:

 

Double-click the .p12 file created in the previous step. In the wizard, select Local Machine and click Next.

 

SubjectAltName08

 

By default, the wizard has already selected the .p12 file you want to install. Click Next.

 

SubjectAltName09

 

Provide the password you defined for your certificate when you export it to P12 format. Make sure the Import options marked in the image are select and click Next.

 

SubjectAltName10

 

Select Place all certificates in the following store, then select Personal.

Click Next.

 

SubjectAltName11

 

Finally, review the summary of the options you have chosen and click Finish.

 

SubjectAltName12

 

8. Import and binding the certificate in the application server (IIS)

Follow the steps below to import certificate into IIS:

 

Open the IIS Management Console.

 

Once you have a valid certificate for your server, specify the bindings in the Work portal's web site (by default, at Default Web site). Add a new binding. Select the HTTPS type and type the port, usually 443 for HTTPS. Then select the SSL certificate using the certificate mentioned before.

 

https_04

 

Click OK to save this configuration.

 

All sites including the Default Web Site, like the Work Portal, Sites editor, or published sites, can now be accessed using the HTTPS protocol.

 

note_pin

When using HTTPS, consider editing the web.config file to specify <add key="PROTOCOL" value="HTTPS"/>.

This applies when using case links in process notifications, as described at Notifications using case links.

 

For further security recommendations at the IIS click here.  

 

9. Adding the certificate to your server trusted store

To include the certificate to be trusted by the server Certification Authorities Store. Open the Windows Run dialog box, by searching in windows the word run:

 

https_05

 

On the Console File menu, click Add/Remove Snap In. Select Certificates and click Add.

 

https_06

 

Select Computer Account and click Next. Select Local computer and click Finish. Then click Ok.

 

Open the Personal Folder and Click the Certificates folder. Right-click the Certificate with the friendly name created with the command. Select All Tasks, and click Export.

 

https_08

 

 

In the Wizard, click Next. Select Yes, export the private key and click Next. Export the certificate in PFX format.

 

https_09

 

Define a password and Click Next.

 

Define a folder and a name to export the file. Finally click finish. Now you have the certificate exported.

 

Under the same MMC window, now select the Trusted Certification Authorities. Right-click the Certificates folder and click All Tasks / Import.

 

https_10

 

In the import wizard, click Next, and then Select the file exported previously. In the next step, type the password used when exporting the certificate. and Select the Trusted Root Certification Authorities store.

 

After downing that if you review your certificate in the IIS the status must be OK.

 

https_12

 

You can also review that the certificate is valid when you access your Work Portal, clicking the lock icon next to the URL:

 

https_13

 

note_pin

If the browser stills show the certificate as not valid in Chrome, make sure that you reset Google Chrome (closing all tabs opened in the task manager) and reset your web application server (IIS).