User Tools
OpenSSL is a free utility that comes with most installations of MacOS X, Linux, the *BSDs, and Unixes. You can also download a binary copy to run on your Windows installation. And OpenSSL is all you need to create your own private certificate authority.
The process for creating your own certificate authority is pretty straight forward:
1.Create a private key
2.Self-sign
3.Install root CA on your various workstations
Once you do that, every device that you manage via HTTPS just needs to have its own certificate created with the following steps:
1.Create CSR for device
2.Sign CSR with root CA key
You can have your own private CA setup in less than an hour. And here’s how to do it.
Create the Root Certificate (Done Once)
Creating the root certificate is easy and can be done quickly. Once you do these steps, you’ll end up with a root SSL certificate that you’ll install on all of your desktops, and a private key you’ll use to sign the certificates that get installed on your various devices.
Create the Root Key
The first step is to create the private root key which only takes one step. In the example below, I’m creating a 2048 bit key:
openssl genrsa -out rootCA.key 2048
The standard key sizes today are 1024, 2048, and to a much lesser extent, 4096. I go with 2048, which is what most people use now. 4096 is usually overkill (and 4096 key length is 5 times more computationally intensive than 2048), and people are transitioning away from 1024.
Important note: Keep this private key very private. This is the basis of all trust for your certificates, and if someone gets a hold of it, they can generate certificates that your browser will accept. You can also create a key that is password protected by adding -des3:
openssl genrsa -out rootCA.key 2048 -des3
You’ll be prompted to give a password, and from then on you’ll be challenged password every time you use the key. Of course, if you forget the password, you’ll have to do all of this all over again.
The next step is to self-sign this certificate.
openssl req -x509 -new -nodes -key rootCA.key -days 1024 -out rootCA.pem
This will start an interactive script which will ask you for various bits of information. Fill it out as you see fit.
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Oregon
Locality Name (eg, city) []:Portland
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Overlords
Organizational Unit Name (eg, section) []:IT
Common Name (eg, YOUR name) []:Data Center Overlords
Email Address []:none@none.com
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. But before you can start your own certificate authority, remember the trick is getting those certs in every browser in the entire world.
Install Root Certificate Into Workstations
For you laptops/desktops/workstations, you’ll need to install the root certificate into your trusted certificate repositories. This can get a little tricky.
Some browsers use the default operating system repository. For instance, in Windows both IE and Chrome use the default certificate management. Go to IE, Internet Options, go to the Content tab, then hit the Certificates button. In Chrome going to Options and Under The Hood, and Manage certificates. They both take you to the same place, the Windows certificate repository. You’ll want to install the root CA certificate (not the key) under the Trusted Root Certificate Authorities tab.
However, in Windows Firefox has its own certificate repository, so if you use IE or Chrome as well as Firefox, you’ll have to install the root certificate into both the Windows repository and the Firefox repository.
In a Mac, Safari, Firefox, and Chrome all use the Mac OS X certificate management system, so you just have to install it once on a Mac. With Linux, I believe it’s on a browser-per-browser basis.
Create A Certificate (Done Once Per Device)
Every device that you wish to install a trusted certificate will need to go through this process. First, just like with the root CA step, you’ll need to create a private key (different from the root CA).
openssl genrsa -out device.key 2048
Once the key is created, you’ll generate the certificate signing request.
openssl req -new -key device.key -out device.csr
You’ll be asked various questions (Country, State/Province, etc.). Answer them how you see fit. The important question to answer though is common-name.
Common Name (eg, YOUR name) []: 10.0.0.1
Whatever you see in the address field in your browser when you go to your device must be what you put under common name, even if it’s an IP address. Yes, even an IP (IPv4 or IPv6) address works under common name.
If it doesn’t match, even a properly signed certificate will not validate correctly and you’ll get the “cannot verify authenticity” error.
Once that’s done, you’ll sign the CSR, which requires the CA root key.
openssl x509 -req -in device.csr -CA root.pem -CAkey root.key -CAcreateserial -out device.crt -days 500
This creates a signed certificate called device.crt which is valid for 500 days (you can adjust the number of days of course, although it doesn’t make sense to have a certificate that lasts longer than the root certificate).
The next step is to take the key and the certificate and install them in your device. Most network devices that are controlled via HTTPS have some mechanism for you to install. For example, I’m running F5’s LTM VE (virtual edition) as a VM on my ESXi 4 host.
Log into F5’s web GUI (and should be the last time you’re greeted by the warning), and go to System, Device Certificates, and Device Certificate.
In the drop down select Certificate and Key, and either past the contents of the key and certificate file, or you can upload them from your workstation.
After that, all you need to do is close your browser and hit the GUI site again. If you did it right, you’ll see no warning and a nice greenness in your address bar.
How to create an intermediate certificate authority (CA)
By Jamie Nguyen — Aug 25, 2013
This tutorial is part of a series on being your own certificate authority, which was written for Fedora but should also work on CentOS/RHEL or any other Linux distribution.
An intermediate certificate authority (CA) is an intermediary that can sign certificates on behalf of the root CA. A certificate can be signed by the intermediate CA, which itself is signed by the root CA, so a chain of trust is formed.
Having an intermediate CA makes life more convenient in the event that your key is compromised. Using your root CA, you can revoke your compromised intermediate CA and create another. It also allows you to keep your root CA completely off-line (eg, on an encrypted USB) and you will only have to use your root key to revoke or renew your intermediate certificate.
If you are acting as your own CA, you can easily create an intermediate CA. You should have a root key and root certificate inside the /etc/pki/CA directory. Use a completely new directory to hold your intermediate CA and any certificates that you sign with it. In this case, the directory tree is created in /etc/pki/CA/intermediate:
# cd /etc/pki/CA/intermediate
# mkdir certs crl newcerts private
# chmod 700 private
# touch index.txt
# echo 1000 > serial
A different directory tree is being used, so you must let openssl know about this. First, copy your configuration file to the new directory:
# cp /etc/pki/tls/openssl.cnf /etc/pki/CA/intermediate/openssl.cnf
Then ensure dir=/etc/pki/CA/intermediate is specified within the [ CA_default ] section of your new configuration file.
Important: Whenever you want to create and sign a certificate with your intermediate CA, you must pass the -config /etc/pki/CA/intermediate/openssl.cnf option so that openssl knows which directory holds your intermediate CA.
Now you can create the intermediate key. Like the root key, this should be kept very secure.
# cd /etc/pki/CA
# openssl genrsa -aes256 -out intermediate/private/intermediate.key.pem 4096
Enter pass phrase for intermediate.key.pem: secretpassword
Verifying - Enter pass phrase for intermediate.key.pem: secretpassword
# chmod 400 intermediate/private/intermediate.key.pem
Using the intermediate key, create the intermediate CSR. Make sure the Organizational Name matches the one set for your root CA. You can leave the extra attributes empty.
Important: The default digest is SHA-1. SHA-1 is considered insecure. Pass the -sha256 option to use a more secure digest.
# cd /etc/pki/CA
# openssl req -config intermediate/openssl.cnf \
- sha256 -new -key intermediate/private/intermediate.key.pem \
- out intermediate/certs/intermediate.csr.pem
Enter pass phrase for intermediate.key.pem: secretpassword
You are about to be asked to enter information that will be incorporated
into your certificate request.
Country Name (2 letter code) [XX]:GB
State or Province Name (full name) []:London
Locality Name (eg, city) [Default City]:London
Organization Name (eg, company) [Default Company Ltd]:Alice CA
Organizational Unit Name (eg, section) []:Intermediate Certificate Authority
Common Name (eg, your name or your server's hostname) []:Alice CA
Email Address []:alice@example.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
You can now sign your intermediate CSR with your root CA to issue an intermediate certificate. Use the v3_ca extension as this is a CA certificate.
NB: Note that you can avoid having to specify -keyfile and -cert options by changing the private_key and certificate options in the [ CA_default ] section of your openssl configuration.
# cd /etc/pki/CA
# openssl ca \
- keyfile private/ca.key.pem \
- cert certs/ca.cert.pem \
- extensions v3_ca -notext -md sha256 \
- in intermediate/certs/intermediate.csr.pem \
- out intermediate/certs/intermediate.cert.pem
# chmod 444 intermediate/certs/intermediate.cert.pem
To verify that your intermediate certificate is valid, run the following:
# openssl verify -CAfile /etc/pki/CA/certs/ca.cert.pem \
/etc/pki/CA/intermediate/certs/intermediate.cert.pem
/etc/pki/CA/intermediate/certs/intermediate.cert.pem: OK
When an Internet browser or any other application tries to verify a certificate signed by your intermediate CA, it will also need to verify the intermediate certificate against the root certificate. To do this, it will need a certificate chain file. This is created by simply concatenating your intermediate certificate and root certificate together:
# cd /etc/pki/CA
# cat intermediate/certs/intermediate.cert.pem \
certs/ca.cert.pem > intermediate/certs/ca-chain.cert.pem
# chmod 444 intermediate/certs/ca-chain.cert.pem
At this point you are ready to issue and sign certificates using your intermediate CA. To verify that certificates signed by your intermediate CA are valid, you must test them against the certificate chain file:
# openssl verify -CAfile /etc/pki/CA/intermediate/certs/ca-chain.cert.pem \
/etc/pki/CA/intermediate/certs/www.example.com.cert.pem
/etc/pki/CA/intermediate/certs/www.example.com.cert.pem: OK
