Using OpenSSL toolkit to create a CSR for Skype for Business integrations

To acquire a server certificate from a Certificate Authority (CA), a certificate signing request (CSR) has to be created and submitted to the CA.

You can use Pexip Infinity's inbuilt Certificate Signing Request (CSR) generator to assist in acquiring a server certificate from a Certificate Authority.

An alternative common way of creating a CSR is through the OpenSSL toolkit (http://www.openssl.org), available for Windows, Mac and Linux.

If you are using OpenSSL to create a CSR that includes SAN entries, you must prepare a special configuration file to use with the openssl req command. Here are two example configuration files to use when integrating Pexip Infinity with Skype for Business: one that matches our example public DMZ deployment and one that matches our example on-premises deployment (for the Europe-located pool of Pexip nodes), that show the configuration required (see Certificate creation and requirements for Skype for Business integrations for more information).

If you use this configuration file as the basis for your own CSR creation, the only elements you normally need to modify are the items in bold (i.e. px.vc.example.com, px01.vc.example.com and px02.vc.example.com in the public DMZ deployment example, and the equivalent confpool-eu values for the on-premises example). Replace these names with the SAN entries as required for your certificate i.e. with the actual names as used in your deployment, and add extra DNS.n altNames entries if required depending on the number of Conferencing Nodes you have.

In the section above marked [req] we have added req_extensions = v3_req — this ensures that the section called [v3_req] is included when creating the CSR. Inside the [v3_req] section, the line subjectAltName = @alt_names ensures that the section [alt_names] is used when deciding which SAN entries this CSR should include. The SAN entries themselves are listed as DNS.1, DNS.2, DNS.3 and so on and are set to the required values for each node.

Also, note that the Common Name entry that we intend to use is duplicated into the Subject Alternative Name list (as the value of DNS.1 in our examples) — this is best practice and ensures that all of the nodes can use the same certificate.

We will store this configuration file as example.cnf and then create our CSR using the following command syntax:

openssl req -out <csr file name>.csr -new -newkey rsa:2048 -nodes -keyout <private key file name>.key -config ./example.cnf

In the above command, we tell openssl to:

• use <csr file name>.csr as the name of the generated CSR key file. You must replace <csr file name> with your required name — typically this is named after the required common name, e.g. px.vc.example.com.csr (for our public DMZ example) or confpool-eu.vc.example.com.csr (for our on-premises example).
• use <private key file name>.key as the name of the generated private key file. You must replace <private key file name> with your required name — this is typically named in a similar fashion to the .csr file, e.g. px.vc.example.com.key (for our public DMZ example) or confpool-eu.vc.example.com.key (for our on-premises example).
• read our configuration file with the -config ./example.cnf parameter at the end of the command.

Note that the openssl command will vary depending on which operating system you are using. When running this command, the user will be prompted to input values as shown by our public DMZ example contents in gray below:

Country Name (2 letter code) []:NO
State or Province Name (full name) []:Oslo
Locality Name (eg city) []:Oslo
Organization name (full company or person name) []:Pexip
Organizational Unit Name (eg section) []:IT
Email Address []:admin@example.com
Common Name []:px.vc.example.com

The result of the openssl command will be to create two files: px.vc.example.com.csr and px.vc.example.com.key in our public DMZ example, or confpool-eu.vc.example.com.csr and confpool-eu.vc.example.com.key in our on-premises example. The .csr file is the actual CSR, while the .key file is the certificate private key. The private key should be kept secret, while the CSR file contents should be submitted to the CA for signing. After the CA has signed the CSR, the certificate will be ready for uploading.