Setup Your Own Certificate Authority (CA) on Linux and Use it in a Windows Environment

In this
previous post, I deployed a test IIS Server and used a self signed SSL
Certificate to encrypt the HTTP traffic. I am sure everyone have seen
this page in Internet Explorer:
When I clicked “View Certificate”, I saw the following:
We can see that certificate is issued by the same entity as the
site-name itself. We can also see that the Root CA is not trusted. Since
this is a self-signed Certificate, you are the Root CA in a manner of
speaking. My goal is to get rid of that message and to become a
“trusted” Certificate Authority (CA) in my local Windows Environment.

Choosing a free Certificate Authority software

If we take a look at this wikipedia page, we will see the following list of available software:

Using OpenSSL Commands to Setup a CA

DogTag, EJBCA, and OpenCA were full blown
Public-Key Infrastructure (PKI) applications and I didn’t need all of
the extra functionally. There are a lot of examples on how to setup your
own CA with openssl:

I have done that before and when you are managing a lot of different
certificates the process is not very scalable. Also, if you don’t keep
doing it, you have to re-trace your steps to remember how the setup
works. There is also a Perl script that is included to ease the CA setup, that script is called CA.pl.
Depending on your Linux distribution you have find the right package
that contains that script. Here is where I found it on my Fedora
install:

TinyCA

This time around I wanted a pretty GUI that will handle all of the openssl
commands for me and store the certificate database as well. Maybe I am
getting lazy? or hopefully efficient. Among the other applications,
TinyCA stood out the most. I found many guides on how to use it:

That didn’t stop me; I downloaded the application and installed it
manually. After setting up my Root CA, the application crashed with the
following error:

Use of uninitialized value $mday in concatenation (.) or string at /usr/share/perl5/Time/Local.pm line 116, line 3.
Day '' out of range 1..31 at /usr/local/tinyca2/lib/OpenSSL.pm line 1050.

I found this bug and the issue was with a later version of openssl
(which I had on my Fedora 18 install). The fix was included in Debian
based distributions. However I was running Fedora and I didn’t want to
keep patching the software manually, if it kept having issues. So I
decided to try out gnomint.

Install Gnomint and Create a Root CA Certificate

Luckily Gnomint was part of the Fedora packages, so a simple:

yum install gnomint

Took care of all my troubles. Then running gnomint launched the GUI for me:
Then I clicked on “Add Autosigned CA certificate” and it showed me the “New CA” dialog:
Here is what I entered for my new CA certificate:
Then if you click “Next” you will see the “New CA Properties” window:
Choose what you think is necessary; the higher the bit count the
better the encryption is. Click “Next” and you will be asked to provide
the “CRL Distribution Point”. This is included with the Root CA
Certificate. If a certificate is revoked, people can check for that at
this “Destribution Point”/Link. I won’t be a public CA, so I left this
blank:
I then clicked “OK” and my new Root CA Certificate was created:

Generate a new Certificate Request and Sign it with your Root CA Certificate in Gnomint

At this point we can generate a Certificate Signing Request (CSR) by clicking on “Add CSR”:
After “Inheriting CA Fields” we can click “Next” and fill out the Request:
I went ahead and requested for a “wildcard” (*.domain.com)
certificate just to have one certificate cover my test windows domain.
This way I can import one Certificate on both of my IIS servers.
Clicking “Next” will take us to the Encryption details, I left the
defaults here (I know with Windows as long as it’s above 2048 bits then
it should work):
Clicking “OK” created the CSR:
To “Sign” the CSR, just right click on it and select “Sign”:
and the following window will show up:
Click “Next” and it will ask you to choose the CA to sign with:
After clicking “Next” we choose how long the certificate is valid for and what it can be used for:
The defaults were fine with me, clicking “OK” finished the process and I now had a signed certificate:

Check out the Gnomint Database

Save your database in gnomint and a file called ~/.gnomint/default.gnomint will be created. That is just an sqlite3 database, so we can check out the contents to make sure it looks good. So go ahead and open up the database:

Export the Signed Certificate in PKCS #12 Format from Gnomint

Now we need upload our signed Certificate to our IIS server to make
sure it works okay. First, let go ahead and export the certificate from
Gnomint. This is done by right clicking on our Cerficate and selecting
“Export”:
After that, you will be presented to choose the format of the certificate. Choose “Both Parts”:
After clicking “Next”, you can choose to save the exported file on your computer. I called the file wild-elatov-local.pfx and stored it on my Desktop:
After clicking “Save”, you will be asked to password protect the file:
Click “OK” and you will now have the exported certificate in PKCS #12 format.

Confirm the Contents of a PKCS #12 Format Certificate

We can just use the openssl utility to quickly check out the contents of the certificate:

The Export password and the PEM password are the same one that we
used during the “Export” process from Gnomint. The above looks good: the
Issuer is correct and so is the subject.

Import the PKCS #12 Certificate into the IIS Server

Upload the .pfx file to the IIS server:
Then start up IIS manager:

inetmgr

Then click on “Server Certificates”:
After you double click on “Server Certificate” you will see a list of
current certificates, I only have the self signed certificate:
Now click on “Import” from the top left and the Import Certificate
Dialogue will show up. Hit “Browse” and point to our certificate and
enter the Export password:
After you click “OK” you will see the newly import Certificate:
Now if you click on “Default Web Site” you can click on “Bindings” from the left pane:
Then select the “https” binding:
Lastly select “Edit” and select the newly imported SSL certificate:
To test out the new Certificate, open up the browser to the same site
and you will still see the same “ssl” warning, but if you click on
“View Certificate” you will see the following:
We can see that the “Issue By” and the “Issue To” fields look correct.

Now that we our own CA we need to import it to our Domain Controller
and push it to any machine that is part of our domain. This way any
computer part of the Domain will trust our SSL certificates. First we
need to export our Root CA from Gnomint.

Export Root CA Certificate from Gnomint

To export the Root CA Certificate we just have to do the same thing
as with the regular Certificate. Right click on the Certificate and
select “Export”. During the Export process choose “Public Only” for the
format:
If all is well you should see a succesful export:

Import the Root CA into the Windows DC Server

Upload the Root CA Certificate to the DC Server and then launch the “Group Policy Management” console:

gpmc.msc

Next let’s expand the following hierarchy: Forest -> Domains -> “elatov.local” -> “Group Policy Objects”:
Then right click on “Defaul Domain Policy” and select “Edit” and you will see the following:
Now let’s expand the hierarchy as follows: “Default Domain Policy”
-> “Computer Configuration” -> “Policies” -> “Windows Settings”
-> “Security Settings” -> “Public Key Policies” -> “Trusted
Root Certification Authorities”:
Right click on “Trusted Root Certification Authorities” and select “Import”, then point to the Root CA:
After clicking “Next” it will let you know that it will add the certificate into the “Trusted Root Certifications Authorities”:
Lastly click “Next” and then “Finish” and you will the following message:
And in the end you will see your root CA imported:
Now you can close the GPO consoles.

Get the new Group Policies to the Windows Clients

Now that we have added our Root CA Certificate to our Group Policy,
we need to update the policy on the client. Open up a command prompt on
the Windows 7 client and run:

Confirm the Root CA Certificate is on the Domain Joined Windows Client

Now that we have synced the new Group Policies from our Domain controller, we should see our Root CA. On the windows client run:

certmgr.msc

and the “Certificate Manager” will start up:
If you expand “Trusted Root Certification Authorities” -> “Certificates”, you should your Root CA in there:
Now going to the site: shows me the following page without any warnings:
And checking out the SSL certificate we see the following:
It’s trusted and I feel so much safer.