This blog post covers some experiences I’ve had with Public Key Infrastructure (PKI) implementations, namely troubleshooting of PKI related issues. As a consultant before doing any work on an existing PKI infrastructure I would always check the health of the environment before doing any new configuration. I have also come across issues with certificate templates and deploying certificates in a healthy infrastructure where people have spent ages trying to figure out what is going on when the issue has been relatively simple, and this blog gives some pointers as to what the issues may be.
Wouldn’t it be nice if we could see a view of the health of an Enterprise Certification Authority (CA) – well, we can do this with pkiview.msc on a server with Certificate Services installed. Information about PKI in the enterprise is stored in Active Directory (AD), and the PKIview tool looks in here for the CA certificates and Certificate Revocation Lists (CRL) for each CA present. It also validates the Certificate Revocation List (CRLS) are accessible, and can show if they have failed or are about to potentially expire.
Here, there is a problem!
In the above example, there was a problem with the http location – causing errors checking CRLs and finding the CA certificate. This could cause issues on various systems that have certificates as part of their workings and rely on being able to check CRLs to function. As an example, I have seen this before in an 802.1X implementation where clients had computer certificates for network access – the NPS server could not see the CRLs due to an issue with accessing the CDP locations and as a result would not let any machines on the network. :-0
Once this was corrected:
So it is important when designing a PKI infrastructure to have some resilience to ensure clients always have access to CDP and AIA locations.
I have also seen errors in PKIview where a company has an offline root CA, but no process (e.g. calendar reminder!) for updating the root CA certificates or CRLs meaning they expire – the first anyone knows is when there is a problem. If I was a PKI administrator I would fire the PKIview console up on a regular basis to make sure everything is running smoothly and no potential nasty surprises. It is amazing how many teams that look after certificate services are not aware of this tool.
Certificate services console
This is useful to be able to examine if we have any expired certificates, revoked certificates or denied certificate requests. If you have tried to enrol for a cert and it has been denied, then you are probably looking at fixing something in the certificate template or AD rather than the client end. If you are having certificate issues, try locating and examining the certificate in this console to see if it has expired or been revoked or something else in the properties is amiss.
It may sound obvious, but on a server where the Certificate Services role is installed, there will be a dedicated event log under server roles which can be examined for clues.
This tells me that the user I’m trying to enrol with requires an email name set in its AD account properties – this is stopping the certificate being issued. Requiring this has been set in the Certificate Template.
A common problem when trying to deploy certificates to users or computers, especially through autoenrollment is that the certificate does not appear in the appropriate (user or computer) personal store on the client machine.
Reasons for this may include:
- The user or device does not have appropriate permissions set in the certificate template. To get a certificate a user needs read plus enrol or autoenroll permission. Here, domain users may have a problem.
- If any autoenrollment settings are applied via GPO, does a gpresult show the GPO has been applied and the user or computer is in the right groups?
- If the correct permissions exist on the template, the correct GPOs applied, and the user / computer has been added to the appropriate groups has the object SID has been refreshed? (I’ve seen people add users to a CA template permissions group and waste hours googling why they can’t get a cert where a log off / on or reboot to update the group membership was all that was needed)
- A firewall exists between the Issuing CA and the client. One way of checking is to perform a new certificate request from the certificates MMC locally on the client logged on as the appropriate user. Can you see a list of certificate templates that includes the one you want? If not visit the firewalls. If you can see them, do they have errors against them? Some you may have no permissions on. If you can enrol manually but not automatically there may be an issue with autoenrollment settings in group policy.
- Check the certificate services console – has your request reached but then been denied by the CA at least it has got that far– for example some templates may require the presence of an email address to build a certificate and if it is not in the AD properties the request will fail.
Certutil is a command line utility that can be run on both a Certificate Services server (many CA operations are scriptable using certutil for example backups) and also on a client to assist with troubleshooting, for example it can be used to verify certificates and CRLS. A separate blog could be dedicated to this, in the meantime information on its usage can be found here: https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/certutil
Hopefully this blog has given you some pointers if you are having any certificate-based issues.