Background
Being a pentester I often have to tackle the issue of self-signed certificates on the internal network. All our automated tools (Nessus, Nexpose, OpenVas) flag several SSL issues related to untrusted certificates, weak ciphers, weak hashing algorithms and self-signed certificates. The usual advice is to disable weak ciphers, and to re-issue and re-sign the certificates. The big question from customers is “But why should we purchase certificates for servers that are not accessible on the public internet?” and “Purchasing and signing certificates can get expensive in large quantities, It is impractical and I do not have the budget!”
The solution is to create your own Certificate Authority (CA), this can then be pushed out to the domain through active directory, or put onto new workstations and servers as part of the build process.
This will provide:
Trust (Identification)
Encryption (Privacy)
Integrity (Data Protection in Transit)
OpenSSL
OpenSSL (http://www.openssl.org/) is available on all Operating Systems (OS), Windows, Linux, Unix, Mac OSX. This piece of open-source software is essentially all that is needed to create your own CA.
The process for creating a CA follows:
Create Certificate
Self Sign
Install new CA on servers/workstations
Afterwards, every device that needs a new certificate:
Generate new certificate
Generate Certificate Signing Request (CSR)
Sign CSR with the new CA Certificate
How to Create the Root CA
Create Private Key
First create the root private key (the example uses a key size of 2048 bits):
Now we could use 1024,2048, or 4096 bits. 4096 bits requires more processing, due to the much larger keyspace, 1024 bits is adequate but slightly weaker. In the interests of security and computation overhead, we have compromised with the middle value of 2048-bits.
Important: This is your private key, keep it safe! You probably want this created on a stand-alone machine, buried deep in your data-center/safe-room protected by extra security.
Optionally, you can encrypt the root private key:
The downside is you’ll be asked for the password on every signing request; which could become tedious.
Sign the Certificate
The following command will start an interactive script which will ask you for various bits of information. Fill it out as to what you deem appropriate:
Once done, this will create an SSL certificate called rootCA.pem, signed by itself, valid for 1024 days, and it will act as our root certificate. The interesting thing about traditional certificate authorities is that root certificate is also self-signed.
Install the CA Certificate
Now install this new root CA on all of your devices.
I am not covering the process here, as it would be a lengthly process describing how to do this on all OSs, and System-Administrators should already know how to do this!
Creating New Device Certificates
Create Certificate
To create a certificate, first you’ll need a private key:
Generate a Certificate Signing Request (CSR)
Next create the CSR:
Again, you’ll be prompted to fill in various bits of information. The most important thing to remember is the common name or cn should match the hostname of the device/server, specifically matching the Fully Qualified Domain Name (FQDN). For example: Server1.acme-industries.org.uk
If it doesn’t match, even a properly signed certificate will not validate correctly and you’ll get the classic “cannot verify authenticity” error.
Sign the CSR with the Root CA
The following command creates a signed certificate called device.crt which is valid for 365 days
Optional: Convert a PEM certificate file and a private key to PKCS#12 (.pfx .p12)
Install the New Certificate on the Device/Server/Workstation
This should be a trivial task. If in doubt consult the application’s services documentation on installing and configuring the use of SSL certificates.
References
http://www.openssl.org/