How to: Create a Self-Signed SAN Certificate on PowerShell

How to: Create a Self-Signed SAN Certificate on PowerShell

In the past I have wrote about creating self signed certificates on different architectures as well as creating SAN (Subject Alternative Name) Certificates. The main twist is always how to create SAN certificates as the need for them seems to be on the rise. In case you are not familiar, a SAN certificate in simple terms is one certificate which can be used for more than one thing. A regular certificate only protects one domain or a very particular DNSName, for example: KX. CloudIngenium.com. Modern day CAs will issue certificates for the root domain “CloudIngenium.com” and the subdomain “Kx. CloudIngenium.com”. So if you wanted to protect www.CloudIngenium.com or www.JCBauza.com, you would need a separate certificate. Using SANs you can include additional DNSNames you want your certificate to be good for. But I digress.

Getting back on topic, in Windows 8 (or Windows Server 2012) using PowerShell there is a new command at your disposal for creating Self Signed Certificates. This used to be somewhat of a pain, but Microsoft finally wrapped it all up in one nice PowerShell commandlet for you: New-SelfSignedCertificate. Isn’t that awesome!

So, easy as you would expect, here is the syntax:

Syntax:

New-SelfSignedCertificate [-CertStoreLocation <String>] [-CloneCert <Certificate>] [-DnsName <String>] [-Confirm <SwitchParameter>] [-WhatIf <SwitchParameter>] [<CommonParameters>]

To make the magic happen, all you really need is the -DnsName and the -CertStoreLocation. Providing those two parameters you will be golden. One thing to keep in mind is that the first DnsName you provide is going to be the Common Name of the certificate, so you might want to pick that one. Here is one example if you want to get started:

New–SelfSignedCertificate –DnsName cloudingenium.com, *.cloudingenium.com, JCBauza.com, *.JCBauza.com –CertStoreLocation cert:\LocalMachine\My

Once done, you will get an output confirming the location the certificate was placed as well as the Thumbprint and Common Name/Subject of the new certificate:

Directory: Microsoft.PowerShell.Security\Certificate::LocalMachine\My

Thumbprint                                 Subject

———-                                 ——-

10E0CC054B5818262CJF6C7D9BB2E2546A2B4BC8 CN=CloudIngenium.com

So, voilá! It even gets it installed on your local certificate store (as indicated by the CertStoreLocation parameter.

As with any self signed certificate, they are not trusted by any computer. If you need to avoid those warnings while you perform your tests using the certificate, you will need to add it to the Trusted Root CA store of each computer that is going to access the (web)server using that certificate. Simply export your certificate using the Certificate MMC (you don’t need to export the private key + it is no recommended you do so for this exercise) and then import it into the Trusted Root CA store of each computer.

Below is the general help available for the command in case you are curious about how to tweak the parameters:

New-SelfSignedCertificate Help

Description         The New-SelfSignedCertificate cmdlet creates a self-signed certificate for testing purposes. Using the CloneCert parameter, a test certificate can be created based on an existing certificate with all settings copied from the original certificate except for the public key. A new key of the same algorithm and length will be created.         If an existing certificate is not being cloned, then an SSL server certificate with the following default settings is created: Subject:   Empty Key:   RSA 2048 EKUs:   Client Authentication and Server Authentication Key Usage:   Digital Signature, Key Encipherment (a0) Validity Period:   One year Delegation may be required when using this cmdlet with Windows PowerShell® remoting and changing user configuration. Parameters –CertStoreLocation <String>         Specifies the certificate store in which a new certificate will be stored. The current path is the default value. Required? False Position? Named Default value . Accept pipeline input? False Accept wildcard characters? False –CloneCert <Certificate>          Identifies the certificate to copy when creating a new certificate. The certificate being cloned can be identified by an X509 certificate or the file path in the certificate provider. When this parameter is used, all fields and extensions of the certificate will be inherited except the public key (a new key of the same algorithm and length will be created) and the NotAfter and NotBefore fields (the validity period for the NotBefore field is set to ten minutes in the past). Required? False Position? Named Default value Accept pipeline input? true (ByValue) Accept wildcard characters? False -DnsName <String>         Specifies one or more DNS names to put into the Subject Alternative Name extension of the certificate when a certificate to be copied is not specified via the CloneCert parameter. The first DNS name is also saved as Subject Name and Issuer Name. Required? False Position? Named Default value Accept pipeline input? False Accept wildcard characters? False –Confirm <SwitchParameter>         Prompts you for confirmation before running the cmdlet. Required? False Position? Named Default value Accept pipeline input? False Accept wildcard characters? False –WhatIf <SwitchParameter>         Shows what would happen if the cmdlet runs. The cmdlet is not run. Required? False Position? Named Default value Accept pipeline input? False Accept wildcard characters? False InputsMicrosoft.CertificateServices.Commands.Certificate The Certificate object can either be provided as a Path object to a certificate or an X509Certificate2 object. Outputs System.Security.Cryptography.X509Certificates.X509Certificate2 An X509Certificate2 object for the certificate that has been created.