the ongoing struggle: man vs machine
Monthly Archives: July 2012
10/07/2012Posted by on
By running your own certificate authority, you can establish the basis for an enterprise trust infrastructure which will enable you to generate certificates that identify your internal websites, devices and staff. Some of the potential uses of this infrastructure are generating certificates to identify internal websites, staff smart card logins, and providing encrypted network communications.
The easy way to create a CA is to create a single root CA which would sign all your certificates. For an organisation that will issue many certificates, this design is inflexible and poses a security problem.
An organisation of significant size should create a single root CA, and multiple sub CA’s. This allows sub CA management to be delegated to different groups depending on what their use is. It also allows for an entire sub CA certificate to be revoked if you find that it has been misused.
This article is intended to be a basic introduction to setting up a Debian based CA using the GUI tool TinyCA2 and OpenSSL. By no means am I an expert in this area, and the notes below should be taken as a general guide only.
This guide assumes that you have installed Debin and the network is functioning
1. Log into debian
2. TinyCA2 is part of the contrib sources, which need to be enabled. Go to System>Administration>Software Sources
4. Open up a terminal window and issue the command apt-get install tinyca
Install all required packages as requested by apt.
5. .Create a tinyCA2 shortcut on the desktop by right-clicking on the desktop and selecting “Create Launcher”
6. Set Type to be Application, Name to be TinyCA2, Command is tinyca2
The Root CA
We will now create the first CA in our hierarchy, the root CA. This CA should only be used to sign certificates for sub CA’s.
1. Open TinyCA2 from the desktop shortcut.
2. The first time you start TinyCA2 you are asked to create a new CA. This will be your root CA. Fill in the details as per the screenshot, customising to your environment as you see fit.
Name and Data for CA Certificate Common Name should be the same
Password should be random, long and difficult to guess. You will only need this password when creating new sub-CAs.
3. When ready, click OK
4. The CA Configuration window will appear. This screen defines how the CA will operate. At this point some important decisions need to be made.
Select weather this CA is critical or not critical
Change the Netscape Certificate Type to “SSL CA, S/MIME CA, Object Signing CA.”
The two revocation URL fields need to be set. This is the address of a web server where the certificates revocation list is accessible to client PCs. To determine if a certificate is valid, this list will be consulted to check if a certificate has been revoked. This cannot be changed after the creation of the CA so you need to have a location setup now. It is recommended that this be hosted on a server separate to the CA itself.
The two policy URL fields relate to a webpage where people can go to read about the policy of the issuing CA, and any certificate use policy you may have. You can make the actual document later, but you must set the web address now.
5. Click ok to accept settings. After the CA has been created you will be presented with the main TinyCA window, open to your root CA.
The Subordinate CA
Now we will create our first sub-CA. This may be the first of many sub-CA’s you create, depending on your specific requirements.
One annoying thing you will notice with TinyCA2 is that none of the buttons on the toolbar have captions or tooltips. This is annoying, although it is very safe to click each one to see what it is (you can cancel every screen).
1. Make sure you have TinyCA2 open with your root-CA displayed. On the CA Tab, click the “Create a new Sub CA” button, which is the 3rd button from the right.
2. Fill in the details for the sub-CA. The CA Password field is the password of the root CA (Or in the case of multiple sub levels, the password of the parent CA). The second password asked for is a password for this CA, which needs to be different from the root-CA password. This password will be used for signing client certificates.
3. Click Ok when satisfied.
The sub_CA is created and you are returned to the main application window with the Sub-CA opened.
4. Exit TinyCA2.
Export the Root-CA and Sub-CA Certificates
In order for this new CA hierarchy to be of any use, it needs to be trusted by the devices that need to use it’s services. Possibly the best way to achieve this in Microsoft domain networks is by using Group Policy. Where this is not available, the files may be imported manually into web browsers on client PCs.
1. Open TinyCA2. You will be presented with a list of all the CA’s currently in use.
2. Select the root-CA and click ok
3. On the main TinyCA2 window, click the “Export CA Certificate” button, which is the second from the right.
4. Select a location to save the certificate file, and click save.
5. Do the same procedure with the Sub-CA.
6. Transport the certificate files for the Root-CA and the Sub-CA to your windows domain controller.
7. Open the Group Policy Management Console.
8. Make a new group policy object and link it to the appropriate location in your domain.
9. Expand Computer Configuration>Windows Settings>Security Settings>Public Key Policies>Trusted Root Certificate Authorities
10. Right-click in the right hand pane and select import
11. Follow the wizard to import your root-CA certificate, and your sub-CA certificate.
12. Exit Group Policy
13. Once Group Policy refreshes on your client PCs, they will trust your new Certificate Authority infrastructure.
Export and publish the Certificate Revocation List (CRL)
One final step remains before our CA infrastructure is complete. We must export the CRL list and publish it to the web location we specified when we established our CA.
1. Open TinyCA2 and select the root-CA.
2. Click the “Export CRL” button, which is the right most button.
3. Select a location for the file, enter the CA password, and select how long this CRL file is valid for.
4. Transport the CRL file to the webserver that will host the file, and ensure it is accessible from the address that you defined earlier.
5. At this point you may wish to create a webpage that outlines your CA policy and place this on the webserver also.
The world of a penguin blog