AD Enterprise CA certificate expiring and unable to renew

first i have no experience with windows systems.....

1) If a root CA expires then all derived certificates will expire... all servers, etc. etc. will distrust the master certificate. (In AD that probably means the Domain going down).

2) All certificates are created from a template (which tells a lot of field values, so you don;t have to type them, or can accept the default) , at least it works like that in openssl, so why not in later built systems.
Your error message tells you the template has a date in it which is well before the end of validity ie. creating a certificate that would be expired immediately so such a certificate would make no sense. Check the templates for issues around the dat.

BTW. For a CA certificates it is quite normal to have a 10 year life span., also use the same key as was used before then all current certificates will stay valid. (if you can also the serial number.. in effect you want the same certificate with new end dates.  (Another thing can be the hash algorithm SHA-1 was used a lot, and is now INVALID. (yesterday a collision attack was published:
"SHA-1 is a shambles". it has been announced deprecated for a while now)

If you view the CA root certificate, it will display the name of the server in the list of CRL (certificate revocation list). See Details tab of the CA certificate properties and look for CRL Distribution  Points entry:
URL=ldap:///CN=CAName,CN=servername,CN=CDP , ...

Logon to the server, it can be a member server or even a DC with the Active Directory Certificate Services (ADCS) role installed.

Renew CA Certificate:
https://www.youtube.com/watch?v=Q-1Y1ZI9R6k 

If the CA server is still using SHA1 certs then it will need updating to use SHA256:
https://support.symantec.com/us/en/article.tech246255.html

If you can't find Root Ca, then your subordinate CA will expire and you need to build new AD integrated CA

If you are sure that you won't get offline root ca stress, build new enterprise CA now and start enrolling new certs from now to mitigate impact

So when you say build new enterprise CA, do you mean:

1) create new root CA
2) create new subordinate CA(s)
3) issue new certs

?

or can you create a new root authority and then issue new certs to your existing subordinates?

You can either create single enterprise root CA (AD Integrated CA)
OR
You can create new standalone offline root CA and issue new subordinate cert to current sub CA and it will further issue to clients (I have not tested this - but test this it should work)
OR
U can setup new standalone offline root CA and new Sub CA

we are considering all 3 options and we are thinking about trying the new standalone offline root CA first. I have questions:

- do you think this has the greatest chance for success? Or do you think the first option (single enterprise root CA, AD Integrated CA) would be better?
- once we build the root CA (found these instructions: https://stealthpuppy.com/deploy-enterprise-root-certificate-authority/), how do we make the existing enterprise CA start using the new cert from the new root CA?
- do we have to create the new root CA with same exact system name as the old one or can we use a new one?

If you create new standalone offline Root Ca, then you also need to work upon CDP and AIA points which are very crucial

U may refer below article for same
https://www.experts-exchange.com/articles/32336/CA-Validity-Period-Extension-and-CA-Certificate-Renewal-Process.html

I also believe the current offline root CA (windows server 2008 R2) is using SHA-1; do we need to preserve this to avoid issues?

suppose we go with the AD integrated option (which you seem to recommend over new offline root CA). How do we go about getting resources on the network to start using that certificate server (once built) instead of the existing one with the certificate that is going to expire? Does it just automatically take over once it presents itself on the network?

AD integrated CA will be automatically published to all clients and servers and you just need to create / choose appropriate certificate templates and may be you can use template autoenrollment feature

SHA1 should not be the problem for internal root CA certificate, however you even can build new offline root CA with SHA 256

You need to publish new offline root ca certificate to AD
refer article in last comment

Better You deploy new SHA 256 Offline root CA, then it will issue sub CA cert with SHA 256 only

If you build with SHA1, then you need to make little config and ensure that cert it issues will be with SHA 256

how would one go about creating/choosing certificate templates? would I need to log into the existing sub-ordinate and review the templates currently in use?

also, if we proceed with the new offline root CA, let me see if I have a handle on the steps required:

1) create new server (workgroup) and install certificate services (using this article: https://stealthpuppy.com/deploy-enterprise-root-certificate-authority/)
2) update CRL and AIA info with FQDN of new server
3) publish root CA certificate to AD
4) generate CSR on existing enterprise CA, create cert on root CA, then install on existing enterprise CA

Yes, you are right on above plan.

thank you Mahesh! at the moment, I am most anxious about the CRL/AIA portion so we'll see how that goes and I will update the thread.

Article posted earlier have clear info on same

another question: do you have a good article on  how to publish offline root CA certificate to AD?

SHA1 is really obsolete for Certificates and stuff that is stored long times.
(A collision attack to be able to create duplicates only takes up to USD 10K, so if someone thinks they can take over your systems en get more from you that the 10K investment a certificate with SHA1 will not protect you).

So SHA256 or better hashes are needed.  For datacom SHA1 can still be used as there one needs a collision for each packet. That is too expensive still.

Mahesh,

With regards to the CRL/CDP/AIA portion, I find this to be quite confusing and am worried about doing this part properly.

- Do we absolutely have to do this part?
- If so, do you have specific steps I can follow? If in an article (perhaps this one: https://www.experts-exchange.com/articles/32336/CA-Validity-Period-Extension-and-CA-Certificate-Renewal-Process.html), can you outline exactly which section/steps we need to follow?
- with regards to publishing root CA to AD, I found an article (see https://michaelpoore.com/2016/03/howto-publishing-offline-root-ca-certs-and-crls/) that states you need to copy over CER and CRL files; is that right?

Step 1.3 – Configure AIA and CDP Extensions

Step 1.4 – Publish Root CA Certificate and CRL to Active Directory

Above two sections and sub sections provide you all information to publish Root cert and CRL to AD for standalone root CA

U are right that you need to copy CRL and certificate file manually

I also have this article that walks through some of the CRL/AIA steps:

https://stealthpuppy.com/deploy-enterprise-root-certificate-authority/

Do these steps cover what needs to be done as well?

Both articles have same steps but your article missing steps for AIA part, it only talks about CDP/CRL

Mahesh,

We are working through the process and I am stuck on this part in the instructions (section 1.3.2.2) as I don't know if we need the delta cRL allowed part. We have already added the URL for the CDP; do we need to add another using some kind of different syntax?

so I believe we have set up a new Root CA and now need to generate new sub ca certificate for existing sub CA. How do I do this? Help!

or can I just renew and submit request to new Root CA?

If your new root CA is in the trusted store of ALL systems i don't see why it couldn't.. from a certificate point of view.
One just needs a valid chain to a trust anchor (the CA certificate being trusted).
(I have no experience on windows systems though).

Delta CRL is only exists with AD integrated CA servers and hence that step is needed on Sub CA server

To generate CSR, use steps under heading "Option 1 – When the issuer is a Standalone Root CA" in same article

To submit CSR to root CA, open RootCA url on sub ca machine and supply it, then approve it on root ca server and download certificate on sub ca server, for that use palo alto article mentioned in 1st comment
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClWOCA0

I believe we managed to get the SubCA certificate renewed successfully (or issued a new cert) so that is working. What we are running into now is issues with SCCM. We imported the new Root CA certificate in site configuration but several functions (e.g., pushing apps, updates) are failing. Any insight as to why this might be?

I don't see how SCCM needs certificate for pushing updates etc, it must be different issue

thanks everyone!