Skip to content

Instantly share code, notes, and snippets.

@PSGM
Last active May 5, 2023 08:02
  • Star 3 You must be signed in to star a gist
  • Fork 2 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save PSGM/53963a0876e1f627ea3d to your computer and use it in GitHub Desktop.
Creating a self-signed wildcard certificate for server authentication in a Windows environment

Creating a self-signed wildcard certificate for server authentication in a Windows environment

We are increasingly using, or being required to use, SSL-encrypted sessions (or technically, TLS-encrypted sessions) for application services. In technical terms, because the Fully Qualified Domain Name (FQDN) in the Uniform Resource Locator (URL) used by a client to access a service needs to match the Common Name (CN) in the certificate used by that service, we potentially have a proliferation of certificates (at least one per server) that need to be available to clients

One approach to addressing this proliferation is to use wildcard certificates that match multiple FQDNs within a domain. Below is a discussion on generating self-signed wildcard certificates as a way of addressing this

What is a certificate used for in HTTPS? As I understand it

  • The certificate is used for server authentication. In effect the client is determining that the web service it is addressing is the service on whose behalf the certificate was issued; only the service on whose behalf the certificate was issued can successfully establish the session, no other certificate with a similar name will do
  • Web services can also request a client authentication certificate. For a host of practical reasons this is relatively seldom implemented
  • The service certificate public/private key pair is used as a crucial step in securely establishing a symmetrical session encryption key. The client encrypts a secret using the public key; the service (the only holder of the private key) is the only code that can decrypt that secret. In cryptography terms, it is computationally impractical to compute a private key that matches the public key. A technical description of the handshake sequence is here

Why use self-signed certificates?

  • Self-signed certificates generally meet the criteria for internal services (for example, within the name resolution scope of an Windows Active Directory domain). They are free and easy to create. The client does not need Internet access to validate the certificate. A more technical discussion is found here
  • Self-signed certificates can be used for externally accessible services when there is a closed and limited client set and provided you can resolve the FQDN externally through DNS or other name resolution protocols. It is generally simpler to create an additional external DNS entry than it is to get a Certification Authority to issue you a certificate
  • Self-signed certificates are not appropriate for public web sites, where the client set is unknown or unlimited

Are self-signed certificates innately less secure?

  • An interesting (and fiery) debate
  • The security of a certificate ultimately rests on keeping the private key (and the password protecting it) secure. Never distribute the certificate with imbedded private key to clients
  • It is my understanding that the security of the entire certificate infrastructure ultimately rests on the security of the root Certification Authority certificates; those root certificates are, by definition, self-signed

Why use wildcard certificates?

  • As previously indicated, there is a requirement that the Fully Qualified Domain Name (FQDN) in the Uniform Resource Locator (URL) used by a client to access a service needs to match the Common Name (CN) in the certificate used by that service. If there are many SSL-encrypted services implemented on multiple servers (each with their own distinct FQDN), there may need to be many distinct certificates, one per FQDN. The certificate (public key only) needs to be distributed to all potential clients. In a Windows Active Directory (AD) environment global policy would probably be the most appropriate distribution approach
  • However, with a wild-card certificate, multiple services (multiple servers each with a distinct FQDN) within a common domain can match the certificate, considerably easing the certificate distribution overhead

How should self-signed wildcard certificates be generated?

  • In a Windows environment, using the makecert utility as provided by the Windows SDK or the Visual Studio Tools. Incomplete documentation of the makecert command parameter syntax is found here

Why not use the built-in self-signed certificate generation as found in IIS and RD Gateway, for example?

  • At a minimum the built-in self-signed certificate generation tools appear not to permit generation of wildcard certificates
  • In addition the makecert utility permits
    • generation of certificates with arbitrary common names, including domain name wildcards
    • explicit specification of encryption hash algorithms. In general the built-in tools generate to the lowest common denominator, including the now-deprecated SHA-1 hash algorithm. Makecert implements other hash algorithms, including SHA-512
    • explicit specification of the key length, longer keys are considered more secure
    • explicit specification of the expiry date

How do you generate a self-signed wildcard certificate in the Windows environment?

  1. Find a machine with the Windows SDK or the Visual Studio Tools installed; the makecert command-line utility ships with those. Open an elevated privileges command to the directory containing makecert

  2. Issue a command of the generic form as indicated below.

    makecert -r -pe -n "CN=*.domain.com" -eku 1.3.6.1.5.5.7.3.1 -ss MY -a SHA512 -len 4096 -e 01/01/2040 path\wildcard.domain.com.pfx

    • The Object Identifier (OID) 1.3.6.1.5.5.7.3.1 indicates a certificate for Server Authentication
    • The hash algorithm SHA512 would be appropriate for a current-level Windows environment; older browsers may not support it
    • The filename is essentially irrelevant; you will subsequently export the certificate from the current users personal certificate store
    • The default expiry date appears to be 01/01/2040; the utility apparently only accepts dates in American format mm/dd/ccyy
    • Incomplete documentation of the makecert command is found here. The extended help text generated by the utility itself is more complete
  3. Using the MMC certificate snap-in on the makecert machine open the machines current user personal certificate store

  • Edit the certificate properties, including the friendly name and description. Leave only the Server Authentication purpose enabled. Apply the changes
  • Export the certificate with the private key to a .pfx file. You will need to specify a password to protect the private key; this password will be required when you subsequently import the certificate to the target server
  • Export the certificate without the private key to a .cer file
  1. Import the certificate with private key (.pfx file) on the target server into the Local Machine | Personal certificate store. The password for the private key will need to be specified
  • Be aware that the security of the Server Authentication process relies on the private key (and the password protecting it) being kept secure
  1. Assign the certificate for use in the target application; the dialog will vary depending on the application

  2. Distribute the certificate without private key (.cer file) to the clients; either by mail, file share, or group policy, depending on requirements

  3. Import the certificate without private key into the Local Machine | Trusted Root Certification Authorities certificate store

Technical notes:

  1. The length of the key, as specified in the makecert length parameter, appears to specify the length of the generated public/private key pair. A higher number of bits makes it exponentially more computationally expensive to crack. In practice TLS sessions can be resumed, thus reducing the computational and network transmission overhead of the full session setup
  2. The symmetric key length used to encrypt the data after session establishment appears to be established by negotiation between the client and service, and is not specified by the certificate. In practice the algorithms are block cipher algortithms; the transmitted data length is rounded up to the next multiple of the key length. The negotiated key length for symmetric keys is relatively modest, generally 128 or 256 bits, as discussed here
  3. Self-signed certificates are essentially private Trusted Root Certification Authority (CA) certificates, refer to the installation instructions above. The Microsoft Best practices for Trusted Root certificates implies that the expiry date should be no greater than 25 years hence. This ties in with the default expiry as provided by makecert
@chihabhajji
Copy link

really informative, thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment