Certificate selection when using 802.1x authentication
Hello I have a question on how a certificate is selected from a computers personal certificates when using 802.1x for wireless authentication using Windows NPS server as RADIUS. I have been having issues with users not being able to authenticate to the office WiFi, and after looking at the logs on the NPS server it shows that the computer is giving the NPS server a certificate other than the one belonging to the computer account. There is a list of certificates in the personal certificate store, and the one certificate for the computer account (given by the on prem PKI) is at the bottom of the list. So it looks like it is just choosing the first certificate in the list, and then failing authentication and not giving the correct cert. Shouldn't it go down the list of certs and eventually giving the correct cert instead of the first one in the list and causing authentication to fail? Hope this make sense any insight is appreciated! Thanks.
General Questions PKI
What if the CRL website is down? Are all the certificates that the clients are trying to validate failing? why is internet explorer the best browser for a certificate request? why is ldap not recommended for crl beside it's limitation to domain joined devices? in a 3 tier PKI - are the policy CA domains connected? isn't the registration authority just the issuing ca?
My pki AD infrastructure is in error state or borked, please help! Can't submit a certificate reques
Hello. I have a problem. The root and subordinate certificate authorities had problems some years back. So we re-created a new root CA, however, it was named the same as the ORIGINAL root ca. Then made up and commissioned a new subordinate CA, This sub did NOT share the same name as the old one. The *new* root CA is not on the domain and it's powered off all the time, according to best practice. It's only job is to authenticate the *new* subordinate CA, which does all the cert work. By the way I can't seem to see any certificate authority or PKI information when I use ASDI to look at my schema. I can only see it using AD sites and services, service node, and Public Key Services. When I run pkiview . m sc on my subordinate, i gets red x on both the root and sub. Looking at the root, there's an "Error" listing the subordinate CA. The AIA location 1 and 2 and CDP Location all show as Unable to Download, even after I power up the root ca computer. The listing it's trying to pull LOOKS ok to me, but not sure why it won't react if the machine is up. Except perhaps the root ca is not joined to the domain? Anyway I think I have to sort out my pkiview being unhappy before my REAL problems which are these. The *old* root CA which expired in 2018, is present on ALL my domain joined machines, because it was IN the pki architecture back when it was made. the *new* root ca is nowhere to be found, and must be manually cert loaded into trusted root authority on any machine that I want it to go on. To be honest I'm not sure what certs are working where if everyone only knows about the *old* root ca and not the new one, same name.\ My problem that revealed all this, I'm trying to request a certificate on my subordinate CA, and it will not even let me try to paste in a CSR, as it gives me the error - "No certificate templates could be found. You do not have permission to request a certificate from this CA, or an error occurred while accessing the Active Directory" Can you help me untangle this mess? Advice appreciated, thank you!
Two Tier PKI Hierarchy - ADCS
Hello Friends. In a test lab, I have implemented smart card login to computers (Windows 10). The service was based on a two-layer PKI environment (Offline Standalone RootCA i Enterpise Subordinate RootCA). On the "Offline Standalone RootCA" server in the CRL and AIA lists I only have the lead for the http server. On the other hand, on the Enterpise Subordinate RootCA server, in the CRL and AIA lists, I only have leads for the http and ocsp server. The problem is revoking certificates. With OCSP, revoking certificates issued from a Subordinate server works fine. As you know, in Two Tier, the point is that you can revoke the certificate for the subordinate server if it was broken. So I revoke the certificate for sub and copy the new list to the web server. I wait two three days and check the sub certificate on the client with certutil. The certificate status is "Verified", and the client can login to the computer using the certificate issued by the sub server. I tried "certutil -urlcache * delete" on the client, but it didn't help. Is it possible to somehow make Windows check the status of the certificate issued by the "Offline Standalone RootCA" server when logging in? Because now this implementation of PKI using Two-Tier for smart cards misses the point. Because even if this sub certificate is broken, revoking it will not give me anything. Thank you in advance for your help and best regards.
PKI Root CA with two different domains
Hi, We currently have a PKI config. of 1 rootCA (offline) and two subordinate CAs within our staff domain (ie staff.domain.com) We also have another domain that currently does not have PKI infrastructure, lets call this public.domain.com Since the root CA is not domain joined and its offline, can I configure this in a way where the rootCA also signs the certificates for subordinate CAs in the public.domain.com, there is no trust between both domains and they are not in a forest. So one root CA and two different domains. thank you!
Access denied. 0x80090010 Enroll cert of Windows hello for Business with on-prem PKI CA Server
We have created Certficate Template from on-prem CA Server ( Windows server 2019 ) using this link : https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/rdp-sign-in?tabs=intune However We can not Enroll Certificate Windows Hello for Business Certificate from User's Desktop ( Windows 11 ) and every time error occurred or Access Denied ( Certificate enrollment for Domain\UserName failed to enroll for a WHfBCertificateAuthentication certificate with request ID N/A from -ERCA.Domain.local\Domain-ERCA-CA-1 (Access denied. 0x80090010 (-2146893808 NTE_PERM)) We have also given Read and Enroll permission to EveryOne and Autheticated Users from CA Certficiate template , but still same erro Please advise if anything more can be done to resolve this issue.ADCS / New CA / Chicken or Egg?
Hello, I am fairly knowledgeable about PKI and ADCS, but have a few question about AD behavior after we created a new sub CA. We have a two tier PKI with an offline root, and two subordinate CAs. These have been around for several years, and we have had minimal problems. Our CAs are nearing the end of their lifecycle, so we recently provisioned a new sub CA. We installed the role on the new server, got the offline request signed by the root, and completed the install. I am assuming that when you install the CA certificate onto a new enterprise subordinate CA, it goes ahead and publishes a bunch of stuff to the various AD containers relating to PKI (Certificate Authorities, Enrollment Services, NTAuth, CDP, AIA, etc. This is probably why you need EA permissions on the domain to complete the install.) Anyway, we completed the install and started the CA service. Immediately, the DCs auto-enrolled for the Kerberos Authentication Template. This is not necessarily a bad thing, as we use Smart Card Login (SCL) and the DCs need to have a certificate issued by the new CA. Almost immediately, we began seeing an error when attempting to RDP or login stating "An Untrusted Certification Authority was detected while processing the domain controller certificate used for authentication" and users were kicked back to login. UN/PW/2FA worked, so we were not totally sunk. The issue gradually cleared itself up over the course of a few hours. My theory is that not all workstations and servers immediately got the new CA cert, which would have been propagated through routine GP updates, and that when windows saw domain controllers presenting untrusted domain controller certs, they balked at it. Either that, or the clients were seeing an untrusted cert in NTAuth. So what is the best way to mitigate this? Remove all certificate templates from the new CA before you turn the service on? Let the new CA cert propagate around before you start issuing DC certs? Thank you for the insight!
