Monthly Archives: November 2017

How to Create TLS Certificates using OpenSSL with wildcards in the SAN

UPDATED 2/4/2021
UPDATE 4/16/2021 – Added commands to

Below are the basic steps to use OpenSSL and create a TLS certificate request using a config file and a private key. You will first create/modify the below config file to generate a private key. Then you will create a .csr. This CSR is the file you will submit to a certificate authority to get back the public cert. Once you have the private key and the resulting public certificate, you will chain them all together (including the CA’s public certs) to create a certificate that you will install on a linux server, load balancer or even convert it to a .pfx file for windows. I’ve been doing this for years and it works very well.

Some gotcha’s… If you are creating wildcard certificates, you always have to have the root domain and the *.domain in the certificate.
For example, if you wan to create a certificate with domaina.com and domainb.com, and support all names like www.domaina.com, abc.domaina.com AND domaina.com, you need to have both the *.domaina.com and domain.com in the SAN area of the config file. Look carefully at the file below. you will see both in it.

Create a config file

Modify this config file to use to create your certificate.

## Start of File
# OpenSSL configuration to generate a new key with signing requst for a x509v3
# multidomain certificate
[ req ]
default_bits = 2048
default_md = sha256
default_keyfile = key.pem
prompt = no
encrypt_key = no
# base request
distinguished_name = req_distinguished_name
# extensions
req_extensions = v3_req
# distinguished_name
[ req_distinguished_name ]
countryName = "US" # C=
stateOrProvinceName = "Minnesota" # ST=
localityName = "Your City" # L=
organizationName = "Your Company" # O=
commonName = "domain.com" # CN=
# req_extensions
[ v3_req ]
# The subject alternative name extension allows various literal values to be
# included in the configuration file
# http://www.openssl.org/docs/apps/x509v3_config.html
subjectAltName = DNS:*.domain.com,DNS:domain.com,DNS:domainb.com,DNS:*domainb.com # multidomain certificate
## End of File

Generate a key for the new certificate.

You could re-use a key but that’s not so secure so always generate a new key every time!

openssl genrsa -out <private key file name>.key 2048

Create the CSR request.

Use the .cnf you created in step 1

openssl req -new -key <private key file name>.key -config <DomainName>.cnf -out <csr file name>.csr

Submit your CSR

Open your .csr file in a text editor (Never use Notepad) and copy the contents. Then submit it to an authority (internal for our sake) and then down load your certificate as a base64. If you are going to submit it to an online authority, use a repeatable authority like DigiCert. Don’t use Thawte or Symantec. They are going away soon.

Merge your public key

Merge your public key, intermediate cert, root cert, and private key (in that order) and save it as a .pem file

NOTE: if this is for a public website, you don’t need to add the root cert to the chain. The browsers computers should have that and it’s trusted more if you leave the root out.

Should look like this (replace your public key and private keys at the top and bottom)

-----BEGIN CERTIFICATE-----
### Replace me with the certificate you received from the authority ###
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
### INTERMEDIATE CERT HERE ###
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
### ROOT CERT HERE ###
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
### replace me with your .key file ###
-----END RSA PRIVATE KEY-----

If necessary, convert your cert from PEM to PFX

If you need to convert your cert from .PEM to .PFX. If you dont need a friendlyname, omit that:

openssl pkcs12 -export -out CERTNAME.pfx -in CERTNAME.pem -name "friendlyname"

Copy your certificate over to your server and install it. You can either install it using the Certificates MMC or import it into IIS. If you are using a .pem file and working on linux, you can import the cert into your load balancer of linux server of choice.

How to set screen saver lock screen local policy on a non domain server

After being tasked to set up a screen saver password or a lock screen for inactivity on servers that are not joined to a domain, I decided to post this so it’s easier to find when others are searching for this.

To be PCI compliant, this is a requirement for any servers that are in-scope for your payment system.

For Microsoft Windows 2008 and 2012, it is easy to do but you have to set all three settings below for it to become active. This will enable a screen saver policy that locks your screen after a set time of inactivity. For PCI controlled servers, this is a requirement and must be less than 15 minutes.

This is easily done if the computer is part of an Active Directory domain but not as easily done if they are members of a workgroup.

How to Set the Screen Saver Lock Screen

The procedure is to open MMC snapin and add the Local Computer Policy snapin. To do this, click on the Windows button, and then simply type in MMC. For Windows 2012, select MMC snapin (mmc.exe) and not the Embedded Lockdown Manager.

Then navigate to User Configuration >> Administrative Templates >> Control Panel >> Personalization (as seen in the graphic I’ve attached).

Set the following settings:
Enable Screensaver: Enabled
Password protect the screen saver: Enabled
Screen saver timeout: Enabled with a value of 600

No need to reboot. Just log out and back in and the setting will be applied. Then wait 10 minutes to verify that your screen locks.

Here is a graphic of what needs to be set:

How to set a local policy to activate the lock screen on servers.

How to add a AD CA certificate to Windows 2012 RDP for PCI compliance

For PCI compliance, a requirement is to have RDP port 3389 connect with TLSv1.1 or TLSv1.2 and have the certificate have the same name as the server. Most servers issue self signed certificates which is not acceptable with PCI compliance.

To fix this, you have to re-issue new certificates from a trusted CA. You should use an internal CA within your company to avoid the cost of purchasing and maintaining certificates for RDP services.

How to issue and import a certificate:

Issue a certificate from your Root CA. You can go through the process I’ve outlined to create a certificate using OpenSSL

Import the certificate to the store using MMC and add the Certificates snapin

Move the Root and Intermediate to the correct store

Get the SHA1 thumbprint off of the certificate by opening up the certificate, go to the “Details” tab and scroll down to below the Thumbprint algorythm and selecting the “Thumbprint”
highlight the thumbprint
copy the thumbprint into a Command Shell and remove the spaces and the hidden character at the beginning.

Put the thumbprint in this command and run it on the server

wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="<EnterSHA1ThumbprintHere>"

Restart Remote Desktop Services Note: this will disconnect you from your RDP session.

Log back in and you should not be prompted.

Retest by scanning your computer with Nessus or another approved scanning software.