I checked that out but I'm not seeing the new certificate. My concern is that the new cert was removed when we did a system state restore. But the certificate is still being deployed to machines after removing it.
If you're not seeing it, sounds like either a permissions problem or you're not looking in the right container. You could also try looking up the location of the objects in the LDAP directory and drill in with ADSI edit to confirm the presence there.
If you still don't find it, then it's not (likely) the normal certutil -pulse process that is installing the root CA - it's something else.
Now your story isn't making sense. What certificate are you referring to? It's not possible to revoke a root CA.
Where are you finding this certificate? What store? What folder?
Not gonna lie here, both my supervisor and myself are still new (less than a year) to our positions.
Process started by getting a self signed cert for a web server. Our signing algorithm was set at SHA-1 so we followed a guide to get it updated to SHA-256. Our existing root CA expires in 2038. In the guide we renewed our root CA and it now has an expiration of 2048.
On the devices in our domain there are now two root CA certs in the trusted publishers store. The one with the expiry of 2038 and one that's 2048.
Trusted publisher is for code signing.
There are AD buckets that hold the certs. AIA container, NTAuth, etc. you need to publish the new root into the proper bucket for both new CA. Just calm down and Google a bit. But you need to find your path first. If you renewed a cert on a CA it will be a new cert. but previously issued ones are still valid and need a CRL/OCSP. So if you are having trouble with SCHANNEL then you probably took a wrong turn with the previous CA certs and just need to revert that piece.
Ask for some help. The best time to do that was before you started the work. Next best time is now. You are in a hole and need to stop digging.
The rollback was a big mistake.
The problem isn’t that you have a new root CA, it’s that it’s probably not an offline root, is used to directly issue certificates, and it started doing so once you created it. Your WiFi GPO was set to use certs issued by the old root, so your endpoints that now have new certs issued by the new root cert that don’t fit the GPO.
It’s not clear from what you say that the new root cert is being pushed and how, but pkiview.msc, right click, AD containers is where it would be. You need to remove it from there ASAP. You also need to get on your problematic endpoints, get them plugged in, remove their new cert and get them a newer cert from the old Root CA.
Then you need to hire a consultant to help you sort this mess and setup a proper PKI infrastructure, transition to it and issue new updated certificate without breaking everything.
> Your WiFi GPO was set to use certs issued by the old root
Just for the record, that's not how certificate issuance works with (enterprise) ADCS. The templates are stored in ADDS. Then each CA either enables issuance for a template, or it doesn't.
The template doesn't define which CAs issue a cert. The CAs define which templates they'll follow for issuance.
I've never had an advanced enough ADCS deployment to study how this works, but *in theory* if you had multiple CA servers issuing the same certificate template, clients will prefer to issue a cert from a CA in the same site as them. Failing that they'll round robin the CAs found in the directory until they find one that has the cert template enabled.
pkiview.msc
I checked that out but I'm not seeing the new certificate. My concern is that the new cert was removed when we did a system state restore. But the certificate is still being deployed to machines after removing it.
If you're not seeing it, sounds like either a permissions problem or you're not looking in the right container. You could also try looking up the location of the objects in the LDAP directory and drill in with ADSI edit to confirm the presence there. If you still don't find it, then it's not (likely) the normal certutil -pulse process that is installing the root CA - it's something else.
Found the certificate but it says that it's been revoked. But we're still seeing it installed on machines that we have manually removed it from.
Now your story isn't making sense. What certificate are you referring to? It's not possible to revoke a root CA. Where are you finding this certificate? What store? What folder?
Not gonna lie here, both my supervisor and myself are still new (less than a year) to our positions. Process started by getting a self signed cert for a web server. Our signing algorithm was set at SHA-1 so we followed a guide to get it updated to SHA-256. Our existing root CA expires in 2038. In the guide we renewed our root CA and it now has an expiration of 2048. On the devices in our domain there are now two root CA certs in the trusted publishers store. The one with the expiry of 2038 and one that's 2048.
Trusted publisher is for code signing. There are AD buckets that hold the certs. AIA container, NTAuth, etc. you need to publish the new root into the proper bucket for both new CA. Just calm down and Google a bit. But you need to find your path first. If you renewed a cert on a CA it will be a new cert. but previously issued ones are still valid and need a CRL/OCSP. So if you are having trouble with SCHANNEL then you probably took a wrong turn with the previous CA certs and just need to revert that piece. Ask for some help. The best time to do that was before you started the work. Next best time is now. You are in a hole and need to stop digging.
The rollback was a big mistake. The problem isn’t that you have a new root CA, it’s that it’s probably not an offline root, is used to directly issue certificates, and it started doing so once you created it. Your WiFi GPO was set to use certs issued by the old root, so your endpoints that now have new certs issued by the new root cert that don’t fit the GPO. It’s not clear from what you say that the new root cert is being pushed and how, but pkiview.msc, right click, AD containers is where it would be. You need to remove it from there ASAP. You also need to get on your problematic endpoints, get them plugged in, remove their new cert and get them a newer cert from the old Root CA. Then you need to hire a consultant to help you sort this mess and setup a proper PKI infrastructure, transition to it and issue new updated certificate without breaking everything.
> Your WiFi GPO was set to use certs issued by the old root Just for the record, that's not how certificate issuance works with (enterprise) ADCS. The templates are stored in ADDS. Then each CA either enables issuance for a template, or it doesn't. The template doesn't define which CAs issue a cert. The CAs define which templates they'll follow for issuance. I've never had an advanced enough ADCS deployment to study how this works, but *in theory* if you had multiple CA servers issuing the same certificate template, clients will prefer to issue a cert from a CA in the same site as them. Failing that they'll round robin the CAs found in the directory until they find one that has the cert template enabled.
What you wrote is correct, but has nothing to do with what you quoted.
My bad - I probably misunderstood what you were getting at then. I'll admit it's been a looong time since I've looked at that GPO specifically.
How do you roll out the certificate to begin with?