Learn How To Create Trusted X.509 Certificates On Linux
Creating trusted enterprise certificates on Linux has never been easy, but it can be.
In the traditional process you have to create a private key, create a Certificate Signing Request (CSR), submit the CSR to a Certificate Authority (CA), retrieve the issued certificate, install it, and then remember to renew it before it expires. Not easy. There are lots of opportunities for human error and you have to be very disciplined.
Sure you can skip some of the steps by creating a self-signed certificate, but it won’t be trusted in your enterprise environment without each software component on each system being updated. That only makes life harder and your environment less secure.
CertAccord© Enterprise solves this problem. It makes creating and installing trusted enterprise certificates easy by automating nearly all of the process.
We will examine two methods:
- METHOD 1 – Traditional Certificate Creation using manual processes involving openssl, CSRs, and web pages
- METHOD 2 – Using CertAccord Enterprise to fully automate the creation and future renewals of X.509 certificates
METHOD 1 – Traditional Certificate Creation
The traditional process of creating a trusted certificate on Linux is based on using the OpenSSL command line tool available with nearly all Linux distributions such as Red Hat Enterprise Linux, CentOS Linux, Ubuntu Linux, Debian Linux, SuSe Linux, and many others.
STEP 1 – Install OpenSSL
To get started you need to see if you already have OpenSSL installed. Open a shell and run:
If openssl is installed you will see the OpenSSL version information. If it’s not installed, you’ll get an error like “Command not found”.
To install OpenSSL on Red Hat based Linux which using yum, run the command:
yum install openssl
To install OpenSSL on Ubuntu and other Debian based Linux using apt-get, run:
apt-get install openssl
STEP 2 – Create Key Pair
The private and public key pair is needed to sign the CSR. To create the key pair you need to decide upon a cryptographic algorithm (RSA is the most common) and the bit-size of the key. In this example we will use create an RSA 4096 key (current best practice) and store it in the file
openssl genrsa -out my.key 4096
STEP 3 – Generate CSR
Now we will create the Certificate Signing Request (CSR):
openssl req -new -key my.key -out my.csr
This command will save the CSR to the
my.csr file. You will be prompted to fill-in various fields:
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]:California Locality Name (eg, city) :San Jose Organization Name (eg, company) [Internet Widgits Pty Ltd]:Acme Inc Organizational Unit Name (eg, section) :IT Common Name (e.g. server FQDN or YOUR name) :www.my.com Email Address :firstname.lastname@example.org Please enter the following 'extra' attributes to be sent with your certificate request A challenge password : An optional company name :
STEP 4 – Submit CSR To CA
Take the CSR file (my.csr) and submit it to your enterprise Certificate Authority. How you do this depends on the CA you have. If you have a Microsoft CA, then a user with administrator access to the Microsoft CA has to take the CSR and submit it using the CA Manager.
Once a certificate is created from the CSR you should then receive the certificate file and typically a CA trust file.
STEP 5 – Install Certificate
Copy the certificate file and CA trust file to your Linux system. How you do this will depend on the CA product used and your internal process for certificate creation.
If the certificate is a web server certificate for Apache HTTPD, then you copy the certificate file, the certificate private key (my.key), and the CA trust file to the appropriate directories for your Linux / Apache configuration.
You then need to edit the appropriate Apache HTTPD configuration file to specify the certificate file, private key file, and CA trust file.
METHOD 2 – Creating Certificate With CertAccord Enterprise
Creating and installing certificates with CertAccord Enterprise is simple, easy, and doesn’t take a PKI expert.
For this article we are going to assume your enterprise PKI experts have already installed the CertAccord Enterprise Server and has configured it to work with Microsoft ADCS or other supported Certificate Authority products..
STEP 1 – Install CertAccord Enterprise Agent
If you don’t already have the CertAccord Agent installed, you can install it by copying the CertAccord Agent installer to your Linux system. Then run the installer:
chmod +x ./cmbagent-1.0-linux-x64.run ./cmbagent-1.0-linux-x64.run --mode unattended
This command will install the Agent into the default location of
STEP 2 – Register Agent
export PATH=/usr/local/cmbagent/bin:$PATH cmb register server=myserver
Change myserver to be the hostname of the CertAccord Enterprise Server.
When you run this command, the Agent will download the CA trust information from the server, generate a private key locally (configured to adhere to the policies given by the server), and then submit the registration request to the server.
STEP 3 – Create Certificate
To create a web server certificate for use with Apache HTTPD or other web server, run the following command:
cmb cert create purpose=webserver
This command will automatically create a CSR, submit it to the enterprise CA, and install the certificate once issued. This is all done using the PKI policies configured on the CertAccord Enterprise Server and your enterprise CA. No knowledge of these policies or configuration requires are needed by the Linux system administrator when running this command.
Here is example output:
Creating Certificate PURPOSES: [WebServer] Created certificate 634RJ65d [SUBJECT: "dune.contoso.com" PURPOSES: WebServer EXPIRES: Jul 14 2021 13:52:14 PDT] Saved certificate 634RJ65d [SUBJECT: "dune.contoso.com" PURPOSES: WebServer EXPIRES: Jul 14 2021 13:52:14 PDT] to AgentProfile Apply Certificate 634RJ65d [SUBJECT: "dune.contoso.com" PURPOSES: WebServer EXPIRES: Jul 14 2021 13:52:14 PDT] Exported Certificate 634RJ65d [SUBJECT: "dune.contoso.com" PURPOSES: WebServer EXPIRES: Jul 14 2021 13:52:14 PDT] to /var/cmb/cert/dune.magnicomp.com-webserver.crt Exported PrivateKey Grq8jB3h [RSA 2048] to /var/cmb/cert/dune.contoso.com-webserver.key Applying certificate to Apache HTTP Web Server: ID: 634RJ65d PURPOSE: WebServer COMMAND [/usr/sbin/service apache2 reload] ran successfully Reloaded Apache HTTP Web Server Apply certificate to Apache HTTP Web Server: ID: 634RJ65d RESULT: Succeeded
The output shows that a certificate was created, saved to the local Agent database, and a copy of the certificate was exported to
/var/cmb/cert/dune.contoso.com-webserver.crt. The Apache HTTPD server was also reloaded so that it re-read its configured certificate files.
In addition to creating a certificate from the command line using CertAccord Enterprise, you can also have CertAccord Enterprise automatically push (e.g. “auto enroll”) certificates to end-points running MacOS, Linux, and Windows. End-points can be placed in Device Groups in CertAccord or in Active Directory and then assigned Certificate Mandates which will deploy certificates to all end-points in the specific group.
A few key take-aways:
- Using the CertAccord Agent required no prior knowledge of the enterprise PKI policies for keys or certificates.
- Because the certificate was created by the enterprise CA and is not self-signed, the certificate is automatically verifiable by any application in the enterprise.
- The Agent manages the life-cycle of the certificate. That means it will automatically renew the certificate without any human intervention.
The CertAccord Enterprise Agent is a much easier and simpler means of creating trusted certificates on Linux. It can lower IT costs through automated certificate creation and life-cycle management, improve security by reducing errors in creation and renewals, and be implemented as a bolt-on to your existing enterprise PKI.