Wednesday, July 20, 2011

Creating a wildcard webserver certificate with your internal CA

It is possible to create a wildcard webserver certificate using your internal Enterprise CA based on Windows Server 2008 R2. To do this you need to have a Enterprice CA with the webserver template deployed.

The question you'll probably ask yourself is "Why do i need this?". Well the answer is simple. You probably don't want to use this certificate in a production environment, but you can use it for testing purposes without having you to buy a expensive commercial wildcard certificate. Espessially when the test results are having you deciding that a wildcard certificate is not the way to go.

This type of certificates is also very usefull in a Microsoft Exchange Server 2010 environment, when you are publishing your Office Web App and/or Activesync with an application firewall such as Microsoft Forefront Unified Access Gateway (discussed in a later article) or Microsoft Forefront Threat Management Gateway (TMG).

Since Microsoft Exchange Server 2010 needs a certificate with multiple subject names for the use of technologies like:  "AutoDiscover, Outlook Anywhere, Office Web App and co-excistence scenario's between Exchange Server 2003 and Exchange 2010 (legacy scenario)", using a wildcard certificate eliminates the need of create multiple virtual directories (with IP adresses) and certificates with multiple subject names.

During this proces we are going to create a custom certificate request and proces the request on the internal CA WWW Publishing Service. This article will guide you through the process.

  • First you will need to logon to a Windows 7 or Windows Server 2008 R2 domain member machine;

  • Now open the certificates mmc snap-in using mmc.exe.

Note: During the snap-in add it doesn't matter which account you select because it's only for the creation of the request. It's recommended to use the mmc snap-in on the machine where you are going to use the certificate and also to use the local computer account to proces the request on. This will make it easier you you in a later stadium to import the certificate.

  • Next expand Certificates > Personal and right click on Certificates and choose for All Tasks > Advanced Operations > Create Custom Request;

  • In the Certificate Enrollment Wizard click Next on the Before you Begin page;

  • In the Select Certificate Enrollment Policy page, choose Custom Request > Proceed without enrollment policy and click Next;

  • In the Custom Request page the Template (No template) CNG key is selected. Change this to (No template) Legacy key and click Next. (You can leave the Suppress default extensions checkbox empty and the Request format to PKCS #10);

  • In the Certificate Information page click on Details on the right site next to Custom Request to fold it down and click on the Properties button;

  • In the General Tab fill in a Friendly name of the certifiate and a Description for the purpose of the certificate. This information is visible when your viewing a certificate. You can fill in whatever you like, although it's recommended to use recognizable information such as *;

  • In the Subject Tab you will need to fill in the following information under Subject name. The following table shows you the Type and Values you will need to fill in. (These values are examples)

Common Name*.contoso.comThe name of the certificate. This field is used to identify the certificate. Adding the * before the domain name indicates a wildcard certificate for that domain. You cannot use this when you are using sub-domains. When you are using sub-domains you will need to create a wildcard certificate for that domain.
Organizational UnitITThe name of the OU. In most cases this is the IT department
OrganizationContoso Corp.The name of the Organization where the certificate is for. When you are going to request a commercial certificate the information needs to be the same as registred at the Chamber of Commerce since most certification authorities cross-check this information.
LocationSeattleThe location of the registred location of the organization. Check your Chamber of Commerce.
StateWAThe State of your organization
CountryUSThe country of your organization

  • In the Extensions Tabselect:

    • Under Key usage select the options Digital Signature and Key encipherment. Deselect the option Make these keys usages critical.

    • Under Extended Key Usage (application policies) select the option Document Signing;

  • In the Private Key Tabselect:

    • Under Key options select the Key Size (depending on how secure you want the encryption. Default in Microsoft Environments is a key size of 2048). Because you want to be able to export the certificate for backup purposes select the option Make private key exportable. Leave the other options cleared.

    • Under Key type change the value to Exchange.

  • After you have filled in all information click OK;

  • Back in the Certificate Information page click Next;

  • Now fill in the path and filename where to save the certifcate request file (It's recommended to save the file with the extension *.txt because you need to copy the information in the file with a text editor such as notepad) and leave the file format Base64 and click Finish;

  • Now the request is created. Browse with explorer to the file and open it with your default text editor;

  • Select all information in there and copy it;

  • Open a new browser session (preferably Internet Explorer) and browse to your Certification Authirity Web Service (example:;

  • On the page click on the task Request a Certificate;

  • Click on the task  advanced certificate request;

  • Click on the task Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file;

  • Paste the copied information in the Saved Request field;

  • Under Certificate Template select Web Server and click Submit;

  • In the next screen download the certificate. (If you are going to use the certificate on a domain machine you don't need to download the certificate chain because te CA is already in the Trusted Root Certification Authorities);

The certificate is now ready to use.


  1. Shouldn't the "Extended Key Usage (application policies)" be "Server Authentication" and "Client Authentication"?

    This is how my public wildcard certificate from COMODO looks.

  2. Wow, just noticed the age on this...3 years...

  3. Hi Mick. Lol, this is indeed a rather old post.

    In the extended key usage you specify the usage for the certificate. This can actually be almost anything. In my case, if I remember correctly, I needed the certificate for document signing purposes.

    If you'll need the certificate for website purposes, only having the server authentication usage specified is sufficient though. Most certification providers will include the client authentication too, to make sure mutual TLS is possible. This is however not a requirement. The client authentication is only needed when you require client authentication on the website.