Kdc Certificate Could Not Be Validated Windows 10

[Kym Wash]

Igot some users with Win10, that got this error "KDC certificate could not be validated issue." if they try to logon with Face/PIN (WHFB). It seems to be related that if they wait a couple of minutes until DirectAccess or wifi is connected is working fine.

No issues in eventlog on DCs.

The CRL is public internet facing and working both external/internal for the users.

Related to -US/08361cfd-0c9b-4481-9cc7-00920e374b01/kdc-certificate-could-not-be-validated-error?forum=winserversecurity

Cleanup any Root Certificates that point to non existing CAs within you Local Certificate Store certlm.msc only leaving your active CA server, these can be found in your Trusted Root Certification Authorities and Intermediate Certification Authorities.

I'm hoping someone can help me troubleshoot a certificate verification issue. We are using Casper to request a workstation certificate from our internal Windows CA. The cert gets installed with the proper machine name, the Root and SubCA certs are installed. But the machine cert has the error of 'This certificate could not be verified. The exact same cert template is installed and working on our windows computers. All of the Macs we are running are AD joined, OS 10.12. Discussions such as =209 were helpful to build the request profile but I'm not finding anyone with the issue we're running into.

@johnsonj I've not attempted what you are doing but does the process of getting the certificates from the internal windows CA also add the Internal windows CA root to the system keychain and force it to be trusted. I had problems with smart card login and realized that our internal CA cert was not in the system keychain. Once I added that cert and forced it to be trusted then smart card auth worked. I wonder if you need to prepopulate the internal root cert on your mac's first (I do it by the security command line tool)

Thank you @maxbehr and @bentoms for your responses. The RootCA and the issuing RootCA are both in the System keychain and show as being trusted for my account. I have them being added in the same profile as the Machine cert.

Does the requested template name have to be Machine? That isn't a default template name on the CA. We've tried changing it around and as long as the template name doesn't contain spaces the cert gets installed, just not verified.

@johnsonjj I ran into this issue a while back, I just happened to have an apple guy on site when I ran into this issue, he told me that after 10.9, apple put in a little security message that would break what you are trying to do. So to fix it, you would need to run this little code if OS > 10.8

@bentoms Do you have Basic Constraints set on your root CA? I don't have it specified (none) which doesn't seem to bother the windows machines but drilling into the non validated cert reports an error of certificate status: invalid baseConstraints.CA.

Jamf's purpose is to simplify work by helping organizations manage and secure an Apple experience that end users love and organizations trust. Jamf is the only company in the world that provides a complete management and security solution for an Apple-first environment that is enterprise secure, consumer simple and protects personal privacy. Learn about Jamf.

This site contains User Content submitted by Jamf Nation community members. Jamf does not review User Content submitted by members or other third parties before it is posted. All content on Jamf Nation is for informational purposes only. Information and posts may be out of date when you view them. Jamf is not responsible for, nor assumes any liability for any User Content or other third-party content appearing on Jamf Nation.

But the error is popping for an LetsEncypt intermediate CA certficate which expired yesterday evening. Is the Win Client using its own Root CA list to trust and not the systems one?

On windows PCs, simply browsing to a website using Chrome, Edge etc with updated the client trust store with the required certificates. Browsing to -isrgrootx1.letsencrypt.org/ will prompt Windows to include ISRG Root X1 in its trust store automatically.

So check with the firewall, how to update certificates there. Does it just cache the certificates? Perhaps they have tutorials like they did for pfsense:

-2-5-x-letsencrypt-haproxy-proper-mitigation-of-expiring-le-intermediate-ca/

Also the firewall running my HAProxy and also managing the LE certificates was still using the older intermediate CA certificate when renewing my certificates even though I had a while back installed the new one that has now taken over. After deleting the expired one and then forcefully renewing all 20+ certificates which had to be done one at a time, the Windows NC client was happy again.

We have recently setup 802.1x auth and are using EAP-TTLS auth method. We seem to have it working with our Windows 10 clients at this stage of testing, but I keep getting this popup window titled Ethernet Authentication "Can't verify the server's identity".

I think there is a step we missed when setting up our certificate infrastructure. Do we need to register a certificate for each of our ExtremeControl RADIUS servers (we have 15 total) with our certificate authority (internal active directory domain controller). I know just enough about certificates to be dangerous, but I "think" the client get this message because the server is not "registered" with our CA and therefore the client can't verify the RADIUS servers identity. Just need some guidance on why this is happening and what would stop it. Also, if someone has setup their windows environment to use 802.1x with ExtremeControl servers and EAL-TTLS, please let me know if there is some step-by-step guide out there to follow. Thank you.

Hello,

There are are a few considerations that you may be running into. As Robert indicated above you're using a certificate that cannot be validated and should be replaced with a more appropriate certificate.

One consideration that you may be running into is that the client supplicant needs to be configured with server identity parameters in addition to certificate validation.

Even if you have a commercially signed certificate installed in the RADIUS server, if an end system does not have supplicant configurations for server identity it will prompt a "Trust Anchor" or similar server identity message.

Example seen for wireless:

-networks.my.site.com/ExtrArticleDetail?an=000100189

Thank you for the replies. I will work with my team to get these RADIUS servers setup with our internal CA in our windows domain. I do have multiple RADIUS servers (one at each of 12 sites and 2 at the Data Centers for backups). I will get all of them added to our CA since it will depend on which switch and location the user will use for RADIUS. This is just for wired so far, I still have wireless 802.1x to setup and test.

I would need to test it in the lab to be 100% but, I'm assuming that if that profile is manually created on the client you'll be OK. The problem with certificate validation/server identity trust is typically seen when Windows tries to setup the wireless profile on initial connection.

You appear to be using the default self-signed untrusted certificate that ships with Extreme Control. This certificate is not trusted by any device so the warning presented to clients to 'verify' if they wish to Connect or Disconnect is valid.

Verify that all the details are filled in the "Default" certificate authority in System Certificate Certificate Authority Default? Fill up the details and re-download the client for a fresh installation.

We too all of a sudden started having could not validate certificate errors with our CAA. I updated to verison 19.0.0 GA-Build317 back in April and didn't have any issues until today. I verified the time on our AD server, our client PCs, and XG firewall and all was correct. I then regenerated the certificates, uninstalled CAA, re-imported certificate, and re-installed CAA all with no luck. I was about to update to latest firmware when I decided to just reboot the XG firewall. After reboot of XG firewall, CAA started working. Maybe all I had to do was reboot our XG firewall? Just wanted to share and hopefully save someone out there a little time.

Unfortunately - it could be many things - and lots of app servers and other java 'wrappers' are prone to play with properties and their 'own' take on keychains and what not. So it may be looking at something totally different.

to see if that helps. Instead of 'all' one can also set it to 'ssl', key manager and trust manager - which may help in your case. Setting it to 'help' will list something like below on most platforms.

Regardless - do make sure you fully understand the difference between the keystore (in which you have the private key and cert you prove your own identity with) and the trust store (which determines who you trust) - and the fact that your own identity also has a 'chain' of trust to the root - which is separate from any chain to a root you need to figure out 'who' you trust.

I came across this error while trying to access a https url from my application which was using self-signed certificate.What they provide is a .cert file and I was not sure where to put that. I solved it the following way:

3a8082e126