Generate self-signed SSL certificate in Windows 11/10/Server

When you are working in a localized environment, you might need a self-signed SSL certificate installed on your system. The self-signed SSL certificate is a certificate issued to yourself by you and it is trusted across your system. You can generate the certificate for the current user or for all the users presented on the system. The self-signed SSL certificate will only be trusted across your system or the localized environment and it may not be trusted elsewhere. In this article, we will see the steps to generate self-signed SSL certificate in Windows 11/10/Server.

To create a self-signed SSL certificate, you can use Windows PowerShell. For this, we will use New-SelfSignedCertificate PowerShell cmdlet. The general syntax we will use to generate self-signed SSL certificate is as follows:

New-SelfSignedCertificate -Type Custom -Subject "CN=Kapil Arya,OU=IT Unit,DC=www,DC=kapilarya,DC=com" -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2","2.5.29.17={text}upn=*.kapilarya.com") -KeyUsage DigitalSignature -KeyAlgorithm ECDSA_nistP256 -CurveExport CurveName -CertStoreLocation "Cert:\CurrentUser\My"

Here is the description of parameters used in above code. You can customize them as per your requirement:

Parameters	Usage	Possible values (values used in our certificate are mentioned in bold)
Type	This parameter defines the type of certificate generated.	CodeSigningCert Custom DocumentEncryptionCert DocumentEncryptionCertLegacyCsp SSLServerAuthentication (default)
Subject	It is the most important part of the code. It defines the identity to which the certificate is being issued.	It can contain common name (CN), organizational unit (OU) and domain controller (DC) values. Note that this does not accept wildcard values.
TextExtension	Defines the object identifier, followed by certificate usage, policies, constraints, mappings and subject alternative name (SAN).	Possible values of object identifier: Application Policy. 1.3.6.1.4.1.311.21.10 Application Policy Mappings. 1.3.6.1.4.1.311.21.11 Basic Constraints. 2.5.29.19 Certificate Policies. 2.5.29.32 Enhanced Key Usage. 2.5.29.37 Name Constraints. 2.5.29.30 Policy Mappings. 2.5.29.33 Subject Alternative Name. 2.5.29.17 In this certificate, we are using Enhanced Key Usage. 2.5.29.37. You can use following values with it depending upon purpose of the certificate: Client Authentication. 1.3.6.1.5.5.7.3.2 Server Authentication. 1.3.6.1.5.5.7.3.1 Secure Email. 1.3.6.1.5.5.7.3.4 Code Signing. 1.3.6.1.5.5.7.3.3 Timestamp Signing. 1.3.6.1.5.5.7.3.8 We also used SAN in this certificate. It can have either of these values: UPN: in format [email protected] Email DNS computer name DirectoryName in format CN=name,DC=example,DC=com URL IPAddress RegisteredID in dotted decimal notation, like: 1.2.3.4.5 GUID
KeyUsage	It specifies the key usage in the key usage extension.	CertSign CRLSign DataEncipherment DecipherOnly DigitalSignature EncipherOnly KeyAgreement KeyEncipherment None (default) NonRepudiation
KeyAlgorithm	Defines the algorithm that is used to create symmetric keys for the new certificate.	If define, we can use Elliptic Curve Digital Signature Algorithms (ECDSA), or RSA algorithm. Note that you can ECDSA for better performance and less burden on system. In this code, we’re using ECDSA with Secure Hash Algorithm (SHA) 256. If you’re using RSA, recommended key size is 2048-bit keys. For RSA, usable format is RSA -KeyLength 2048
CurveExport	If you are using ECDSA, you can use this to define how the public key parameters for an elliptic curve key are represented in the new certificate.	CurveParameters CurveName None (default)
CertStoreLocation	You can use this parameter to define the location where your generated certificate will be saved. It can be either saved to personal certificate directory of currently logged in user or to the machine, where it can be available for all the users present on the system.	Cert:\CurrentUser\My Cert:\LocalMachine\My

The above code generates the certificate valid for one years from the date of generation. To extend the date of the certificate, you can check the PowerShell cmdlet information. I believe now we have enough information about the Windows PowerShell code to generate the certificate. Let us see how to actually generate the certificate and make it trusted across your system.

Generate self-signed SSL certificate in Windows 11/10/Server

Manual steps

1. Open administrative Windows PowerShell.

2. In the PowerShell window, paste the code you have customized for your certificate and press the Enter key.

3. In few moments, you will see that certificate is generated. It should be saved to the certificate location you have mentioned in the code.

4. Open Certificate Manager (certmgr) by executing certmgr.msc command. Go to Personal > Certificates. You should be now able to spot your generated self-signed SSL certificate.

5. Double click on the certificate to confirm all the details you have entered via parameters. Note that at this stage, the certificate is not valid and it won’t be accepted because it is not from a trusted root certification authority. To make it trusted, you need to move or place it into the Trusted Root Certification Authorities store.

6. So copy the certificate and paste it to Trusted Root Certification Authorities > Certificates. There will be a security warning appearing which is obvious. You can select Yes in the warning, as you’re installing your own generated certificate.

7. Now double click on the certificate self-signed SSL certificate in Trusted Root Certification Authorities store and you’ll find that the certificate is now OK. This means that your generated certificate is now valid and can be accepted across the system.

Video guide

Checkout this video to illustrate this complete guide:

That’s it!