We have concluded part III with a brief illustration on how CAs connect together forming a trusted CA “Cloud” – and this is exactly how I will refer to it going forward. In this blog we will first create a Public Key Infrastructure (PKI). Secondly, I will get all these piece together through an example.
We will use two servers – one will serve as the Root CA while the second one, will serve as the Intermediate CA
- Install Windows Server on two different servers (virtual / physical) – as a good practice, make sure you give them a relevant hostname; you won’t be able to change it once Certificate Services are installed
- Install Certificate Services on one of the servers – you will have several options here depending on whether your server is part of an AD domain or standalone. I would recommend to go with a Standalone installation; furthermore, you will also have to choose the option respective to an Root CA installation. This process alone will also
- generate the key-pair for this server
- generate and install a self signed Digital Certificate
- Install Certificate Services on the 2nd server – select Standalone Intermediate CA – and point it to the first server – this will:
- generate the key-pair for this server
- trigger a CSR (Certificate Signing Request) which is sent to the Root CA (1st server). Note that Certificate Services will be down since there is no trust between the two servers as yet. Right click on the actual request and select All Tasks -> Issue
- Your certificate should now be generated; you will find it in Issued Certificates folder
- Dbl-click the certificate to open it
- Go to Details tab and click the Copy to File … button – this will effectively export the Certificate
- Do whatever you need to do to get the file back to the Intermediate CA
- Go back to the Intermediate CA and start the service – it will ask you if you wish to install the Digital Certificates
- Confirm installation of the new CA and point the wizard to the location where you saved the file; note that the generated Digital Certificate will include the entire chain i.e. the Root CA’s and the Intermediate CA’s – accept both
To confirm, open the Certificates MMC snap-in – you should see:
- the Root’s Digital Certificate successfully installed in the list of installed Trusted Root Certification Authorities
- the Digital Certificate of the Interm. CA in the list of installed Intermediate Certification Authorities
Let’s assume we need a certificate to be installed on Company-A‘s website; the web-domain is company.com. The first step will be to request the certificate; so we need to issue a CSR. Although we can do so using IIS, the process would be too transparent so we wouldn’t be learning too much out of it.
1. Generate a certificate request using this web-tool. The tools automatically generates the openssl commands (so you neeed to install openssl first; it was already installed on my Mac). Run the generated commands:
So by running the commands above, two files were created: company_com.key (the private key) and company_com.csr (the request)…
- Make sure you save the .key file in a safe location
- Make sure the .csr file is accessible from the Intermediate CA server
2. Submit the request to the CA Server: On the Intermediate CA server, open the Certificate Authority MMC console and Submit New Request …
In the Open file Dialog, you will have to change the file filter to “*.*” to make sure the .CSR file is displayed; select the file and click Open.
3. Issue the Certificate: You should now find the file in the Pending Requests folder; right-click the request and select Issue:
You should now find the certificate in the Issued Certificates folder; to check the certificate matches your expectations, double-click the certificate and check its properties. Below is a screenshot of the Certification Path which to me, looks awesome! 🙂
4. Export the Certificate: You should now export the certificate to a file – go to the Details tab and click Copy to a file … button
5. Install the Certificate to the web-server: Once the certificate has been exported successfully, you can then take it and install it on your web-server – the procedure here would vary based on whether you are using Apache, IIS, or any other Web platform.
Let’s now imagine that a web user browses to company.com website. As a result, the user will download the Digital Certificate from the WWW server – though let’s remember that it includes the Public Key. The actual Digital Certificate is signed by the CA (and therefore encrypted with the CA’s private key).
Upon receiving the Digital Certificate, the user would get a Security Warning on his Internet Browser – the user is then given the choice of accepting or not the Digital Certificate; should it be accepted, the entire public-key chain is also installed – including CA’s. This effectively means the web user will be trusting Company Ltd as well as the actual CA.
Other Related Posts:
- JunOS :: Redistribution Between Three Networks – Part 2/5
- Digital Certificates – Part III – Digital Certificates and Certificate Authorities
- JunOS :: Routing Architecture – RE, PFE & Routing Instances
- Understanding IP MTU & TCP MSS
- MAC Address Table, ARP Table and Unicast Flooding – PART I