Sidebar
Creating a Certificate Authority
<html><p>In order to make use of the TLS encryption features we just enabled by upgrading to a newer version of rsyslog, we need to create SSL certificates for the syslog server, and for each of the syslog client machines that will be communicating with the server. Rather than going out and purchasing SSL certificates from a trusted Certificate Authority (CA), we will create our own CA to generate the certificates for all of the machines.</p> <br /> <p>Being that a Certificate Authority is really just a machine that uses it's own self-signed, private certificate, to generate public and private certificates for other machines. This may sound bizarre, but the root of trust has to begin somewhere, and that is just what the self-signed certificate provides when the CA's public certificate is distributed to the other machines; so that they can verify themselves against the CA.</p> <br /> <p>In order to generate this self-signed certificate we need to use the certtool utility that is part of the GnuTLS tools package – which is not installed by default.</p>
<p>To install GnuTLS:</p></html>
sudo aptitude install -y gnutls-bin
<html><p>Now we need to generate our CA's private key.</p></html>
sudo certtool --generate-privkey --outfile ca-key.pem --bits 2048<html><p>Note: It will take a little while to generate the private key file, as certtool utilizes random input from the machine currently running processes. During this time, it is typically recommended to make the machine do some work to increase the randomness of the input; getting directory listings of random directories with ls, or using cat to display the contents of random files ought to be adequate.</p> <br /> <p>Now we need to generate our CA's public key.<p></html>
sudo certtool --generate-self-signed --load-privkey ca-key.pem --outfile ca.pem
<html><p>The creation of the self-signed certificate will ask for several pieces of pertinent information. Fields can be left blank by simply pressing enter.<br />
I used the following:</p></html>
Country name (2 chars): US Organization name: Lab46 Organizational unit name: Student.Lab Locality name: Corning State or province name: NY Common name: Student.Lab UID: E-mail: Enter the certificate's serial number(decimal): Activation/Expiration time. The certificate will expire in (days): 3650 Extensions. Does the certificate belong to an authority? (Y/N): y Path length constraint (decimal, -1 for no constraint): Is this a TLS web client certificate? (Y/N): Is this also a TLS web server certificate? (Y/N): Enter the e-mail of the subject of the certificate: Will the certificate be used to sign other certificates? (Y/N): y Will the certificate be used to sign CRLs? (Y/N): Will the certificate be used to sign code? (Y/N): Will the certificate be used to sign OCSP requests? (Y/N): Will the certificate be used for time stamping? (Y/N): Enter the URI of the CRL distribution point:
<html><p>You will then be shown the resultant certificate file and asked if the information is correct. I entered 'y'.<p><br />
The file permissions need to be changed for our private key file so that only root can read it, and everybody else has zero access to the file.</p></html>
sudo chown root:root ca-key.pem sudo chmod 400 ca-key.pem
<html><p style=“color:#AA0000;”>If anyone gets their hands on this file, the security of the CA and any other machine using certificates generated by the CA has been compromised.</p> <br /> <p>With both private and public certificates having been generated, our CA is ready to create certificates for the other machines on our network.</p></html>
