Get a free publicly trusted SSL-certificate

This blog post will guide you through the steps of obtaining a publicly trusted SSL certificate with up to 5 domain names, at no cost. There are no hidden costs, ads or referrals involved.

You do need to be able to verify that you own the domain name that the certificate will be issued for. You can do this by either receiving a verification code via email (sent to specific administrative email addresses of the domain) or the ability to publish a text file with a verification code on a webserver running on that domain.

I am using the Chinese certificate provider WoSign. Before you stop reading just because of this, consider that their ONLY involvement in this is procedure to sign your public key. They never see your sensitive private key, which is created on your computer and never leaves your control at any time.

Didn’t you know that your Windows computer most likely already trusts WoSign Root CA? Read my short blogpost Which Root CAs do you really trust?

If you want to verify that your client really trusts certificates obtained using this guide, please visit this link: https://test.tomdemo.se  You should not receive any certificate warnings. If you do, please let me know what browser/device you are using via the comment section below.

There are other ways to obtain free SSL certificates, such as Let’s Encrypt and StartSSL, but at the moment I prefer WoSign, since they allow you to add 5 SAN attributes for free.

Ok, lets go.

Create the key pair

The best option, to reduce the number of steps and also the risk of exposing the private key of the certificate, is to create the key pair directly on the computer that will actually use the certificate. But you can export the certificate and private key when you are done, so you can use any trusted Windows computer for the enrollment process. If you plan to use multiple SAN names, it’s likely that you must export the certificate to other computers anyway.

Normally you specify attributes when creating the key pair and the corresponding CSR (certificate signing request), such as Subject, Validity Time, SAN, Key Usage and so on, but WoSign will ignore all attributes in the CSR, and only use the public key. You specify the attributes in the enrollment flow at WoSign instead.

Certificate requests can be created in many ways, in this guide I am using the MMC snap-in.

Run certlm.msc to open the local certificate store for the computer.

Right-click Personal / Certificates, expand to All Tasks / Advanced Operations and click Create Custom Request:

On the Before You Begin page, click Next:

On the Select Certificate Enrollment Policy page, click Next:

On the Custom Request page, select (No template) Legacy key, make sure that the Request format is PKCS #10, and then click Next:
Note: I choose Legacy key for compatibility reasons, you might want to choose CNG key if you are sure that your services are compatible with this.

On the Certificate Information page, click on the down-arrow next to Details and then click Properties:

Click the Private Key tab. Click the down-arrow next to Key options and change the key size to 2048. Optionally select Make private key exportable (which I recommend, see the update at the bottom of this post why), then click OK:
Note: No other certificate information needs to be entered at this point.

Back at the Certificate Information page, click Next

On the Where do you want to save the offline request? page, enter a path and filename for your certificate signing request, make sure the File format is Base 64, then click Finish:

Now we have created a key pair and a Certificate Signing Request.

 

Create the certificate at WoSign

Direct your browser to the following URL:
https://buy.wosign.com/free/

Add the domain names you want to have a publicly trusted SSL certificate for. Make sure that the cost remains zero (US$0):

You may add additional domain names and also extend the certificate validity to 3 years, but that means that the certificate will no longer be free, and that is not the topic for this blogpost. Note that the cost is not updated until you click outside of the Domain name textbox.

Notice that I added domain names from two different domains, tomdemo.se and mssec.se, just to show how domain verification looks in this scenario.

Now you have to either create an account or login with an existing one. WoSign helps you determine if you created an account with them when you fill in your email address. I use a dedicated email address for this, but I have never received any email from them after enrolling the certificate.

If you have an account, it will look like this (you need to click outside of the Email textbox to trigger the check):

Click on the link forget password? to reset your password (it should be forgot, I know).

It you have not registered an account with the email you provide, you will instead be given the option to Send Verification Email:

Click the Send Verification Email button:
Note: This will start a 30 second countdown, but don’t panic, the only thing that will happen when the countdown reaches zero is that you will have the option to resent the verification code.

The verification email might take a 5-10 minutes to show up in your Inbox, do not request a new verification to fast.

Copy the verification code from the mail that you eventually receive:

Paste the Verification code in the field Verification code.

Enter an Account password for your WoSign account.

Enter the captcha. If it is hard to make out the characters you may click change it to get a new one (it will not reload the page or remove the other info you have entered).

Check the I have read and agree checkbox (you read the agreement, right?  )

Click the Submit request button.

You are now taken to a page that looks like this:’’

If you see Chinese characters, click on the link called ENGLISH at the top of the webpage.

At this point we have created an “order” for a free certificate and supplied the names we want in the certificate, but we have yet to verify that we own the domains and to supply the public key we created earlier.

Click on the link Domain Control Verification.

We can now prove that we own the domain by either using special email accounts (that hopefully are reserved to admins of the domain):

or by placing a special file on the webserver:

I will continue with email verification in this guide.

Select the email address you have access to and click the Click to send verification Email button. A countdown similar to the one when we created the WoSign account appears. Wait until you receive the verification email, that will look like this:

The sender is autovalidation@wosign.com, remember to also check your spam mailbox.

Enter the verification code in the Verification Code field. Also complete the captcha and then click Verify Now:

If the verification succeeds, you will be prompted to verify the next domain (assuming that you entered different domains when requesting the certificate):

The verification of the next domain looks identical, so I do not show those steps here.

Note that once you verified your domain you can later request new certificates (within the same domain) without the verification step, which makes it much easier.

When all domains are verified you are taken to the Generate the Certificate Signing Request(CSR) page. This is a bit misleading, since we do not want the generate the CSR at this point, we want to submit the CSR we have already created.

Open the previously created CSR-file in notepad and copy all of the text:

Make sure that Option 2:Submit the CSR is selected. If you choose Option 1, WoSign will create the public and private key for you, and we do not want this.

Paste the text content of the csr-file in the textbox that says Please paste Certificate Signing Request.

Click Check CSR and make sure the text box on the right says

Encryption algorithm:RSA
Key length:2048bite     (yeah, should be “byte”)

Remember that the file only contains the public key, the sensitive private key is still safely stored on your computer that created the request.

Click the Submit button.

Now your certificate should be issued. Click on the link in the blue box to download a zip file containing your signed certificate:
Note: You will also get an email saying that the certificate is ready for collection. You can ignore this mail.

You will get this message:

This warning is only relevant if WoSign generated the private key and the CSR, the public part of the certificate will be available for download when you login with your WoSign account:

The downloaded zip file contains 4 other zip files, with the certificate and it’s issuers certificates in formats optimized for 3 different webservers:

for Apache
1_root_bundle.crt
2_adfs.tomdemo.se.crt

for IIS
1_cross_Intermediate.crt
2_issuer_Intermediate.crt
3_user_adfs.tomdemo.se.crt

for Nginx
1_adfs.tomdemo.se_bundle.crt

for Other Server
1_cross_Intermediate.crt
2_issuer_Intermediate.crt
3_user_adfs.tomdemo.se.crt
root.crt

 

Import the certificate

The last step is to import the signed certificate to the server that created the CSR.

Extract the file 3_user_adfs.tomdemo.se.crt.

On the server that created the CSR, run certlm.msc to open the local certificate store for the computer.

Right-click Certificate Enrollment Requests / Certificates and click All Tasks / Import:

Note: There are other ways to import a certificate, but this way makes sure that the waiting private key and the imported certificate are correctly associated.

On the Welcome to the Certificate Import Wizard page, click Next:

Browse and select to the file 3_user_adfs.tomdemo.se.crt:

Change to Automatically select the certificate store based on the type of certificate and click Next:

On the Completing the Certificate Import Wizard page, click Finish:

You should see the message The import was successful:

You now finally have a publicly trusted SSL-certificate (with up to 5 domain names), all without paying a single penny:

If you export the certificate you will have the option to include the private key (if you selected this option earlier):

Here are some screenshots of the certificate:

 

Known issue with IIS

If the certificate is flagged as untrusted by clients when using the certificate in IIS, try importing the following certificates – that are included in the zip file – into the Intermediate Certification Authorities / Certificate (only on the IIS server itself!):

• 1_cross_Intermediate.crt
• 2_issuer_Intermediate.crt

The issue here is that when a client initiates a SSL handshake, IIS gives the client all certificates in the certificate path, not only the server certificate. If the Issuing CA is not present in the local store (on the IIS server) it does not sent it to the client. It doesn’t matter that both IIS and the client easily could locate the Intermediate certificate using the AIA attribute in the server certificate.

Note that no changes needs to be made on clients and that the warning it not because the certificate is not trusted, it is that the client cannot find the intermediate CA certificate and therefore cannot identify what Root CA certificate to verify trust for. When it is added to the IIS and given to the client at the SSL handshake, the client “realize” that they trusted the server certificate all along. 

Phew, this became a much bigger blog post than I first imagined. I hope you found it useful!

=== Update 2016-06-03 ===

Some services has issues with the certificate, such as TMG (says Incorrect Key Type) and Exchange OWA (you are returned to the login page when logging in).

Assuming that you made the private key exportable in the first place you can solve this by exporting the certificate and it’s private key to a pfx, import that pfx into Firefox’s certificate store and then do a backup of that certificate in Firefox. This will create a new pfx, that when imported will work with TMG and Exchange OWA.

Note that the issues are not because the certificate is CNG, which many seems to suggest. Remember that we chose Legacy key a few steps up (which is the same as CSP) and not a CNG key: