- Activate BitLocker with manage-bde, PowerShell, or WMI - Wed, Sep 20 2023
- Join Azure Active Directory with Windows 11 - Tue, Sep 12 2023
- Manage enhanced security mode in Microsoft Edge using Group Policy - Fri, Sep 8 2023
Strictly speaking, the standard WAC certificate is a self-signed certificate generated during installation. The subject name and issuer are "Windows Admin Center," and it expires after two months.
Since you normally do not want to live with constant browser warnings, it makes sense to install a proper certificate on the gateway server.
WAC's self signed certificate leads to browser warnings
You can prevent users from avoiding the browser warning by connecting to the WAC gateway via an unencrypted connection by activating the following option during setup:
Redirect HTTP traffic (port 80) to HTTPS
In the same dialog, you will also find the option to generate a self-signed certificate. This certificate is then also only valid for 60 days, and, unlike with the explicit call to the PowerShell cmdlet New-SelfSignedCertificate, there is no way of assigning a specific value to any attribute.
When you install WAC, you can specify your own certificate
As a third option, the setup allows you to enter the thumbprint of a certificate already installed on your computer. If you don't use this option during setup and start with the default certificate instead, you will not find a menu item in WAC to replace it afterwards.
Change WAC installation for a new certificate
Instead, you have to start the setup again by calling the .msi file from which you have installed WAC. The first dialog shows the Change button, which takes you to the dialog of the wizard described above.
To change the certificate, you have to restart the WAC setup
If you do not yet have an SSL certificate for WAC, it makes sense to issue one via an internal certificate authority (CA). In the case of Microsoft's certificate services, you can do this via the MMC-based GUI.
Issuing a certificate via PowerShell or Let's Encrypt
An uncomplicated alternative is the Get-Certificate cmdlet, especially if the WAC gateway is running on Server Core. However, the limitation is that you cannot export the private key of a certificate created with the Get-Certificate cmdlet. Therefore, you have to launch the certificate-signing request from the server on which WAC is running.
If WAC should be accessible from outside the firewall on computers that are not part of the domain, you could get a free certificate via Let's Encrypt.
Determining the thumbprint
The final step is to copy the certificate's thumbprint into the setup soon after installing it into the local store. PowerShell lets you find out this information quickly and easily.
Displaying the thumbprint of the new certificate with PowerShell
To do this, change to the appropriate location in the store, using this command:
Cert:\LocalMachine\My\
If you then call:
Get-ChildItem | select Subject, Issuer, ThumbPrint | fl
It will list all certificates, and you may copy the desired thumbprint from the output.
Wolfgang I don't know how you read my mind but I was just looking this information up this morning! Thank you!!
Must have been telepathy 😉
Any way to do this via command line? Maybe passing the thumbprint to that .msi?
but from what i read you can't use a wildcard certificate.
my organization wont go for purchasing a single cert for this tool.
Great Article
Rich,
I am running a wildcard certificate with no issue. There is nothing that a non-wildcard could do that a wildcard could not. In addition, even if you wanted to have individual certs, you should be getting them for free from Let's Encrypt. There is no excuse to pay for SSL certificates any more.
This is not quite accurate. While using a wildcard cert is easier than maintaining separate certs, it's less secure, and if you don't care about security, why not use a self-signed cert?
The point to certificates is that you prove your authenticity by using the private key to encrypt something and which then should only be able to be decrypted by the public key (this is the bread and butter of asymmetrical encryption). Every device that uses the wildcard cert needs to have a copy of the private key and every device that has the private key is a liability to all of the other devices that are using it. If your private key is compromised, you have to re-key everything that uses it. This is just the cleanup, you also have to worry about what was done with the key before it was revoked. (If you don't care, then there is no point to using certs other than putting on a vail of security by getting rid of the invalid cert warnings).
Wildcard certs only work for hosts of a specific domain, and not subdomains of that domain. For examples:
Exchange server hosting 2 domains, you need the cert to be valid for Domain1.TLD and Domain2.TLD. You would need a UCC cert for that.
RDS server that needs to respond with the internal name of Server.int.domain.com and the external name of Server.domain.com. This is often taken care of with DNS, but there are times when you need it to respond to separate names. Again, you would need a UCC since the wildcard won't work for subdomains.
As for Let's Encrypt, the validity times are very low and needs an agent to continually keep them up to date. That is not always practical. Certs should not be $50 for a single name like from Godaddy. Namecheap has them for ~$8 for a single name.
As far as why not using the self-signed certificate, that's obvious – getting clients to trust it. Would still be encrypted of course but the browsers would complain about it.
For the shared private key, I suppose if your certificate needs are that severe I can see the benefit of having separate certificates for each subdomain. You got me there. But, it does work for WAC.
Still, no excuse to pay for each certificate. More and more providers are moving to the shorter times anyway, so being able to automatically re-issue/re-apply the certificates is becoming more and more required, and should be done in all cases. Should not be manually applying/installing certificates in 2020.
Let's Encrypt certificates support Subject Alternative Name too, so they can be valid for many domains. Even while being wildcard at the same time.