How to act as your own certificate authority (CA)
By Jamie Nguyen —
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.
In cryptography, a certificate authority or certification authority (CA), is an entity that issuesdigital certificates.
Most websites, such as shopping, banking or email websites, need to let their customers know that the connection is secure. Thus, they need to pay a well-known and internationally trusted CA (eg,VeriSign) to issue an SSL certificate. However, this isn’t always necessary. For example, if you’re setting up a virtual private network (VPN) or an intranet website, it might make more sense to issue your own certificates.
Being a CA means dealing with cryptographic pairs of private keys and public certificates. Ideally the cryptographic pairs should be generated in a secure environment, which means a personal laptop or computer that is disconnected from the Internet. It is not recommended to generate any certificates directly on your server.
In this example, the /etc/pki/CA directory will be used to store all keys and certificates. Theindex.txt and serial files act as a kind of flat file database to help you keep track of all your keys and certificates.
Important: Ensure that your openssl configuration file (/etc/pki/tls/openssl.cnf) specifiesdir=/etc/pki/CA within the [ CA_default ] section. Feel free to create your certificates within any other directory, as long as you change the dir= option to match.
cd /etc/pki/CA mkdir certs crl newcerts private chmod 700 private touch index.txt echo 1000 > serial
The very first cryptographic pair we generate includes what is known as a root certificate. The root key (ca.key.pem) generated in this step should be kept extremely secure, otherwise an attacker can issue valid certificates for themselves. We’ll therefore protect it with AES 256-bit encryption and a strong password just in case it falls into the wrong hands:
openssl genrsa -aes256 -out /etc/pki/CA/private/ca.key.pem 4096 Enter pass phrase for ca.key.pem: secretpassword Verifying - Enter pass phrase for ca.key.pem: secretpassword chmod 400 /etc/pki/CA/private/ca.key.pem
Now you can use the root key above to issue a root certificate (ca.cert.pem). In this example, the certificate is set to expire in ten years. As this is a CA certificate, use the v3_ca extension. You will be prompted for some responses, which you can fill with whatever you like. For convenience, defaults can be set in the openssl configuration file.
openssl req -new -x509 -days 3650 -key /etc/pki/CA/private/ca.key.pem \
-extensions v3_ca -out /etc/pki/CA/certs/ca.cert.pem
Enter pass phrase for ca.key.pem:
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) []:Certificate Authority
Common Name (eg, your name or your server's hostname) []:Alice CA
Email Address []:[email protected]
chmod 444 /etc/pki/CA/certs/ca.cert.pem
Armed with your root key (ca.key.pem) and root certificate (ca.cert.pem), you are now ready to optionally create an intermediate certificate authority, jump straight ahead to issue and sign your own SSL certificates, or learn how to revoke certificates.
How to create and sign SSL certificates when acting as a certificate authority (CA)
By Jamie Nguyen —
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.
If you’ve taken the necessary steps to become your own certificate authority, you are now in a position to issue and sign your own SSL certificates.
The first step is to create a private key. If your aim is to enable SSL on a web server, bear in mind that if the key is encrypted then you’ll have to enter the encryption password every time you restart your web server. Use the -aes256 argument if you wish to encrypt your private key.
openssl genrsa -out /etc/pki/CA/private/www.example.com.key.pem 4096 chmod 400 /etc/pki/CA/private/www.example.com.key.pem
The next step is to generate a certificate signing request (CSR). Normally, you would send your CSR to a trusted CA (eg, VeriSign) who will then send you back a signed certificate in exchange for money. You can instead sign it yourself for free.
Make sure that the Organization Name you choose below matches the one set for your CA root certificate. The extra attributes can be left blank. If you are creating a self-signed certificate, you would also use the -x509 and -days options.
openssl req -new -key /etc/pki/CA/private/www.example.com.key.pem \
-out /etc/pki/CA/certs/www.example.com.csr.pem
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) []:Web Certificate
Common Name (eg, your name or your server's hostname) []:www.example.com
Email Address []:[email protected]
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
As you are acting as your own CA, you can use your CA root key (ca.key.pem) and CA root certificate (ca.cert.pem) to sign the CSR (www.example.com.csr.pem) and issue a new certificate (www.example.com.cert.pem).
NB: Note that you can avoid having to specify -keyfile and -cert options by changing theprivate_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 \
-notext -md sha1 \
-in certs/www.example.com.csr.pem -out certs/www.example.com.cert.pem
chmod 444 /etc/pki/CA/certs/www.example.com.cert.pem
If you have followed the intermediate CA tutorial then you can sign the CSR with your intermediate CA instead. Just pass the -config /etc/pki/CA/intermediate/openssl.cnf option and change-keyfile and -cert to the intermediate key and certificate respectively.
The index.txt file is where the openssl ca tool stores the certificate database, so don’t delete it or edit it by hand! It should now contain a line referring to the certificate you just issued:
cat /etc/pki/CA/index.txt V 140825154152Z 1000 unknown /C=GB/ST=London/O=Alice CA/OU=Web Certificate/CN=www.example.com/[email protected]
You can verify the details of your certificate using openssl. Near the top of the output you will be able to see details of the issuer. This is the identity of the CA that signed the certificate, which in this case is your own CA. The subject is the identity of the certificate you just signed:
openssl x509 -in www.example.com.cert.pem -noout -text
Certificate:
...
Issuer: C=GB, ST=London, L=London, O=Alice CA, OU=Certificate Authority, CN=Alice CA/[email protected]
...
Subject: C=GB, ST=London, O=Alice CA, OU=Web Certificate, CN=example.com/[email protected]
...
You can also use openssl to verify the certificate against your root CA:
openssl verify -CAfile /etc/pki/CA/certs/ca.cert.pem \
/etc/pki/CA/certs/www.example.com.cert.pem
www.example.com.cert.pem: OK
You can now use your signed certificate for fun and profit! To allow a service (eg, Apache) to make use of your certificate, the following files need to be transferred to your server:
ca.cert.pemwww.example.com.key.pemwww.example.com.cert.pem
Clients can install your root certificate (ca.cert.pem) into their Internet browser. All certificates signed by you will then be trusted by their browser and they will no longer see a This Connection is Untrusted message. It’s a good idea to create a detached signature for your root certificate with GnuPG; clients can then verify that the certificate they’re installing in their browser really is the correct one.
A more flexible method for the client to add your root certificate is to update the system database of trusted certificates:
cp ca.cert.pem /etc/pki/ca-trust/source/anchors/alice-ca.cert.pem update-ca-trust extract