How to create a self-signed certificate for a domain name for development?
I have subdomain.example.com that I use for development purposes. My web application solution contains a web API etc, that I need to call from external systems, hence I am not using localhost.
I now need to test for SSL and need a certificate for my subdomain.example.com development domain name.
I have tried creating a self-signed certificate as outlined in http://technet.microsoft.com/en-us/library/cc753127(v=ws.10).aspx, but this certificate only works for localhost. Can this certificate be used for my purpose or will I have to create a self-signed for my development subdomain? If I have to create a self-signed certification for my development subdomain, what utility or online service (Free) can I use for this?
Am adding this info because the accepted answer does not seem to address the question fully, or at least didn't solve the problem for me.
With IIS's self-signed certificate feature, you cannot set the common name (CN) for the certificate, and therefore cannot create a certificate bound to your choice of subdomain.
One way around the problem is to use makecert.exe, which is bundled with the .Net 2.0 SDK. On my server it's at:
C:\Program Files\Microsoft.Net\SDK\v2.0 64bit\Bin\makecert.exe
You can create a signing authority and store it in the LocalMachine certificates repository as follows (these commands must be run from an Administrator account or within an elevated command prompt):
makecert.exe -n "CN=My Company Development Root CA,O=My Company, OU=Development,L=Wallkill,S=NY,C=US" -pe -ss Root -sr LocalMachine -sky exchange -m 120 -a sha1 -len 2048 -r
You can then create a certificate bound to your subdomain and signed by your new authority:
(Note that the the value of the -in parameter must be the same as the CN value used to generate your authority above.)
makecert.exe -n "CN=subdomain.example.com" -pe -ss My -sr LocalMachine -sky exchange -m 120 -in "My Company Development Root CA" -is Root -ir LocalMachine -a sha1 -eku 126.96.36.199.188.8.131.52.1
Your certificate should then appear in IIS Manager to be bound to your site as explained in Tom Hall's post.
All kudos for this solution to Mike O'Brien for his excellent blog post at http://www.mikeobrien.net/blog/creating-self-signed-wildcard
From Windows 8.1 and Windows Server 2012 R2 (Windows PowerShell 4.0) and upwards, you can create a self-signed certificate using the new New-SelfSignedCertificate cmdlet:
New-SelfSignedCertificate -DnsName www.mydomain.com -CertStoreLocation cert:\LocalMachine\My New-SelfSignedCertificate -DnsName subdomain.mydomain.com -CertStoreLocation cert:\LocalMachine\My New-SelfSignedCertificate -DnsName *.mydomain.com -CertStoreLocation cert:\LocalMachine\My
Using the IIS Manager
- Launch the IIS Manager
- At the server level, under IIS, select Server Certificates
- On the right hand side under Actions select Create Self-Signed Certificate
- Where it says "Specify a friendly name for the certificate" type in an appropriate name for reference.
- Examples: www.domain.com or subdomain.domain.com
- Then, select your website from the list on the left hand side
- On the right hand side under Actions select Bindings
- Add a new HTTPS binding and select the certificate you just created (if your certificate is a wildcard certificate you'll need to specify a hostname)
- Click OK and test it out.
To Create the new certificate for your specific domain:
Open Powershell ISE as admin, run the command:
New-SelfSignedCertificate -DnsName *.mydomain.com, localhost -CertStoreLocation cert:\LocalMachine\My
To trust the new certificate:
- Open mmc.exe
- Go to Console Root -> Certificates (Local Computer) -> Personal
- Select the certificate you have created, do right click -> All Tasks -> Export and follow the export wizard to create a .pfx file
- Go to Console Root -> Certificates -> Trusted Root Certification Authorities and import the new .pfx file
To bind the certificate to your site:
- Open IIS Manager
- Select your site and choose Edit Site -> Bindings in the right pane
- Add new https binding with the correct hostname and the new certificate
I had to puzzle my way through self-signed certificates on Windows by combining bits and pieces from the given answers and further resources. Here is my own (and hopefully complete) walk-through. Hope it will spare you some of my own painful learning curve. It also contains infos on related topics that will pop up sooner or later when you create your own certs.
Create a self-signed certificate on Windows 10
Don't use makecert.exe. It has been deprecated by Microsoft. The modern way uses a Powershell command.
Open Powershell with Administrator privileges:
New-SelfSignedCertificate -DnsName "*.dev.local", "dev.local", "localhost" -CertStoreLocation cert:\LocalMachine\My -FriendlyName "Dev Cert *.dev.local, dev.local, localhost" -NotAfter (Get-Date).AddYears(15)
Windows 8, Windows Server 2012 R2:
In Powershell on these systems the parameters -FriendlyName and -NotAfter do not exist. Simply remove them from the above command line. Open Powershell with Administrator privileges:
New-SelfSignedCertificate -DnsName "*.dev.local", "dev.local", "localhost" -CertStoreLocation cert:\LocalMachine\My
The resulting certificate
Both of the above commands create a certificate for the domains localhost and *.dev.local. The Win10 version additionally has a live time of 15 years and a readable display name of "Dev Cert *.dev.local, dev.local, localhost".
Update: If you provide multiple hostname entries in parameter -DnsName (as shown above) the first of these entries will become the domain's Subject (AKA Common Name). The complete list of all hostname entries will be stored in the field Subject Alternative Name (SAN) of the certificate. (Thanks to @BenSewards for pointing that out.)
After creation the cert will be immediately available in any HTTPS bindings of IIS (instructions below).
Trust the certificate
The new cert is not part of any chain of trust and is thus not considered trustworthy by any browsers. To change that, we will copy the cert to the certificate store for Trusted Root CAs on your machine:
Open mmc.exe, File → Add/Remove Snap-In → choose "Certificates" in left column → Add → choose "Computer Account" → Next → "Local Computer..." → Finish → OK
Export your cert from your personal store
In left column choose "Certificates (Local Computer) / Personal / Certificates". Find the newly created cert (in Win 10 the column "Friendly name" may help). Right-click this cert → All Tasks → Export... → Next → choose "No, do not export the private key" → Next → choose "DER encoded..." → Next → enter file name and save.
Hint: We deliberately don't use the PFX file format for export. It would include your private key into the export file and you usually don't want your private key to go anywhere!
Import your cert into your Trusted Root CAs store
In left column right-click on "Certificates (Local Computer) / Trusted Root CAs / Certificates" → All Tasks → Import... → Next → choose the file that you just exported → Next → "Place all certificates in the following store: Trusted Root CAs" → Next → Finish.
Use in ISS
Now you may go to IIS Manager, select the bindings of a local website → Add → https → enter a host name of the form myname.dev.local (your cert is only valid for *.dev.local) and select the new certificate → OK.
Add to hosts
Also add your host name to C:\Windows\System32\drivers\etc\hosts:
Now Chrome and IE should treat the certificate as trustworthy and load your website when you open up https://myname.dev.local.
Firefox maintains its own certificate store. To add your cert here, you must open your website in FF and add it to the exceptions when FF warns you about the certificate.
For Edge browser there may be more action needed (see further down).
Test the certificate
To test your certs, Firefox is your best choice. (Believe me, I'm a Chrome fan-boy myself, but FF is better in this case.)
Here are the reasons:
- Firefox uses its own SSL cache, which is purged on shift-reload. So any changes to the certs of your local websites will reflect immediately in the warnings of FF, while other browsers may need a restart or a manual purging of the windows SSL cache.
- Also FF gives you some valuable hints to check the validity of your certificate: Click on Advanced when FF shows its certificate warning. FF will show you a short text block with one or more possible warnings in the central lines of the text block:
The certificate is not trusted because it is self-signed.
This warning is correct! As noted above, Firefox does not use the Windows certificate store and will only trust this certificate, if you add an exception for it. The button to do this is right below the warnings.
The certificate is not valid for the name ...
This warning shows, that you did something wrong. The (wildcard) domain of your certificate does not match the domain of your website. The problem must be solved by either changing your website's (sub-)domain or by issuing a new certificate that matches. In fact you could add an exception in FF even if the cert does not match, but you would never get a green padlock symbol in Chrome with such a combination.
Firefox can display many other nice and understandable cert warnings at this place, like expired certs, certs with outdated signing algorithms, etc. I found no other browser that gave me that level of feedback to nail down any problems.
Which (sub-)domain pattern should I choose to develop?
In the above New-SelfSignedCertificate command we used the wildcard domain *.dev.local.
You may think: Why not use *.local?
Simple reason: It is illegal as a wildcard domain. Wildcard certificates must contain at least a second level domain name.
So, domains of the form *.local are nice to develop HTTP websites. But not so much for HTTPS, because you would be forced to issue a new matching certificate for each new project that you start.
Important side notes:
- Valid host domains may ONLY contain letters a trough z, digits, hyphens and dots. No underscores allowed! Some browsers are really picky about this detail and can give you a hard time when they stubbornly refuse to match your domain motör_head.dev.local to your wildcard pattern *.dev.local. They will comply when you switch to motoer-head.dev.local.
- A wildcard in a certificate will only match ONE label (= section between two dots) in a domain, never more. *.dev.local matches myname.dev.local but NOT other.myname.dev.local!
- Multi level wildcards (*.*.dev.local) are NOT possible in certificates. So other.myname.dev.local can only be covered by a wildcard of the form *.myname.dev.local. As a result, it is best not to use a forth level domain part. Put all your variations into the third level part. This way you will get along with a single certificate for all your dev sites.
The problem with Edge
This is not really about self-signed certificates, but still related to the whole process: After following the above steps, Edge may not show any content when you open up myname.dev.local. The reason is a characteristic feature of the network management of Windows 10 for Modern Apps, called "Network Isolation".
To solve that problem, open a command prompt with Administrator privileges and enter the following command once:
CheckNetIsolation LoopbackExempt -a -n=Microsoft.MicrosoftEdge_8wekyb3d8bbwe
More infos about Edge and Network Isolation can be found here: https://blogs.msdn.microsoft.com/msgulfcommunity/2015/07/01/how-to-debug-localhost-on-microsoft-edge/
I ran into this same problem when I wanted to enable SSL to a project hosted on IIS 8. Finally the tool I used was OpenSSL, after many days fighting with makecert commands.The certificate is generated in Debian, but I could import it seamlessly into IIS 7 and 8.
First we will generate the private key and certificate of Certification Authority (CA). This certificate is to sign the certificate request (CSR).
You must complete all fields that are required in this process.
- openssl req -new -x509 -days 3650 -extensions v3_ca -keyout root-cakey.pem -out root-cacert.pem -newkey rsa:4096
You can create a configuration file with default settings like this: Now we will generate the certificate request, which is the file that is sent to the Certification Authorities.
The Common Name must be set the domain of your site, for example: public.organization.com.
- openssl req -new -nodes -out server-csr.pem -keyout server-key.pem -newkey rsa:4096
Now the certificate request is signed with the generated CA certificate.
- openssl x509 -req -days 365 -CA root-cacert.pem -CAkey root-cakey.pem -CAcreateserial -in server-csr.pem -out server-cert.pem
The generated certificate must be exported to a .pfx file that can be imported into the IIS.
- openssl pkcs12 -export -out server-cert.pfx -inkey server-key.pem -in server-cert.pem -certfile root-cacert.pem -name "Self Signed Server Certificate"
In this step we will import the certificate CA.
In your server must import the CA certificate to the Trusted Root Certification Authorities, for IIS can trust the certificate to be imported. Remember that the certificate to be imported into the IIS, has been signed with the certificate of the CA.
- Open Command Prompt and type mmc.
- Click on File.
- Select Add/Remove Snap in....
- Double click on Certificates.
- Select Computer Account and Next ->.
- Select Local Computer and Finish.
- Go to Certificates -> Trusted Root Certification Authorities -> Certificates, rigth click on Certificates and select All Tasks -> Import ...
- Select Next -> Browse ...
- You must select All Files to browse the location of root-cacert.pem file.
- Click on Next and select Place all certificates in the following store: Trusted Root Certification Authorities.
- Click on Next and Finish.
With this step, the IIS trust on the authenticity of our certificate.
In our last step we will import the certificate to IIS and add the binding site.
- Open Internet Information Services (IIS) Manager or type inetmgr on command prompt and go to Server Certificates.
- Click on Import....
- Set the path of .pfx file, the passphrase and Select certificate store on Web Hosting.
- Click on OK.
Now go to your site on IIS Manager and select Bindings... and Add a new binding.
Select https as the type of binding and you should be able to see the imported certificate.
- Click on OK and all is done.
Another option is to create a self-signed certificate that allows you to specify the domain name per website. This means you can use it across many domain names.
In IIS Manager
- Click machine name node
- Open Server Certificates
- In Actions panel, choose 'Create Self-Signed Certificate'
- In 'Specify a friendly name...' name it *Dev (select 'Personal' from type list)
Now, on your website in IIS...
- Manage the bindings
- Create a new binding for Https
- Choose your self-signed certificate from the list
- Once selected, the domain name box will become enabled and you'll be able to input your domain name.
Another easy way to generate a self signed certificate is to use Jexus Manager,
- Choose a server node in the Connections panel.
- In the middle panel, click Server Certificates icon to open the management page.
- Under Actions panel, click “Generate Self-Signed Certificate...” menu item.