Generating certificate requests with additional subject identities using OpenSSL

The below provides steps to how the process used to create a certificate request to issue to certificate authority server in an internal environment. However, the steps to create the certificate request can be performed if submitting a certificate request to a third party certificate authority.

Firstly, I will create a configuration file (openssl.cnf) to be used generating the certificate request. The certificate request will be created specifying a default key size of 2048 bits, and sha256 digest algorithm. In this example, I will be submitting a certificate request for the server ‘server1.domain.local’ with the additional subject identities ‘server1,’’, ‘server1.domain.local’ and ‘www.dean.local’.

[ req ]
default_bits = 2048
‚Äčdefault_md = sha256
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:server1, IP:, DNS:server1.dean.local, DNS: www.dean.local

[ req_distinguished_name ]
countryName = GB
stateOrProvinceName = Midlothian
localityName = Edinburgh
0.organizationName = Dean Grant
organizationalUnitName = Servers
commonName = server1.dean.local ‚Äč

We will now create the certificate request to send to the certificate authority, to which the original public key generated in the certificate request will be converted to be in RSA format and remove the original file. Once the certificate request has been generated place the in a location which may be accessible for the submission to the certificate authority server.

cd /tmp
openssl req -new -nodes -out server1.dean.local.csr -keyout orig-server1.dean.local.key -config openssl.cnf
openssl rsa -in orig-server1.dean.local.key -out server1.dean.local.key
rm -f orig-server1.dean.local

In this example I am submitting my certificate request to a certificate authority running Active Directory Certificate Services on Windows Server 2012. The certificate request is submitted specifying the ‘WebServer’ certificate template and the certificate request file created previously. If prompted select the certificate authority which will now create certificate file (server1.dean.local.crt) and the certficate chain file (server1.dean.local.pfx).

cd %temp%
certreq -attrib "CertificateTemplate:WebServer" -submit server1.dean.local.csr server1.dean.local.crt server1.dean.local.pfx

The certificate files may now be placed on the server to which you configure encryption, depending on the certificate file requirements you should have the following files available.

server1.dean.local.crt # certificate file
server1.dean.local.pfx # certificate chain file in personal exchange file (.pfx) format.
server1.dean.local.key # private key file

Auto-signing client certificates on Puppet Master Server

I am currently using Puppet to automate infrastructure within a cloud offering, Amazon Web Services (AWS) for those interested!. 

As part of deployment of new instances, I require the client certificate to be automatically signed by the Puppet master server to immediately begin the configuration. 

This can be achieved by allowing the master server to automatically sign all clients (*) certificates, as below:

$ cat /etc/puppet/autosign.conf 

However, this can be perceived to be a security risk as any machine could connect without authorisation and request manifest files which may contain sensitive information. I suppose one other option could be use a filter based on a naming convention (in the below example, the DNS name is used as a match) used internally as below, but again the solution saves time but does not remove the security risk.

$ cat /etc/puppet/autosign.conf 

For those using AWS, I found a great article at where using the EC2 API tools to get the DNS name of the deployed instance and adds this as a trusted client to /etc/puppet/autosign.conf. This then can be run as a CRON job to automatically sign the client certificates on the master server.