> Will this create cross-sign certificates(0-1, 1-0) for SubCA
no, it won't. Cross-certificates are created only during Root CA renewal with new key pair. For intermediate CA certificates cross-certificates are not generated. You only need to copy new CA certificate to AIA location.
> For new CRL, do this need to be published as well using "certutil -f -dspublish" or just coping to AIA/CDP publish location is required only.
CA will automatically publish new CRL when needed and copy it to CDP locations.
> Coping the new CRL to AIA/CDP will replace the old CRL
It shouldn't. A new separate CRL is generated instead. Eventually, you get two separate CRLs for each CA signing key.
> as the existing certificate is still referring to the old CRL file ... how this going to work
yes, that's how things work. Old certificates will refer to CRL signed using old CA key and new certificates will refer to new CRL signed using new CA key.
I have a question regarding IntermediateCA certificate renewal
This is 3 tier PKI hierarchy -- Root(offline) -> Intermediate (offline) CA -> Issuing (online) CAs
Once certificate issued from RootCA (using new Key Pair) and installed/issued on Intermediate CA --
New CeRT/CrOSS CeRT
Will this create cross-sign certificates(0-1, 1-0) for SubCA, in addition to the new cert on IntermediateCA under CertSrv >> CertEnroll folder ?
- if yes then do we need to publish ""certutil -f -dspublish" the new Cert and cross-sign certificate on Domain Controllers considering the Intermediate CA is offline.
or only copying the new Cert file to AIA/CDP will work --- how to deal with this cross-sign certificates .. are they also need to be copied to AIA/CDP publish locations
For new CRL, do this need to be published as well using "certutil -f -dspublish" or just coping to AIA/CDP publish location is required only.
Coping the new CRL to AIA/CDP will replace the old CRL .. so will there be any impact ? as the existing certificate is still referring to the old CRL file ... how this going to work
> So after encoding, it becomes 0x89 0x93 0xF2 0x2C.
yes, that's correct.
Thanks for your concept explaination, There's a more simple way to do multiple byte encoding.
For example, the OID value is 19200300.
1. Convert 19200300 to Hex 0x124F92C
2. 0x124F92C & 0x7F = 0x2C -- Last Byte
3. ((0x124F92C >> 7) & 0x7F) | 0x80 = 0xF2 ---- 3rd Byte
4. ((0x124F92C >> 14) & 0x7F) | 0x80 = 0x93 ---- 2nd Byte
5. ((0x124F92C >> 21) & 0x7F) | 0x80 = 0x89 ----- 1st Byte
So after encoding, it becomes 0x89 0x93 0xF2 0x2C.
Vadims, thank you very much for writing this excellent resource. The PDF version was especially convenient.
© 2008 - 2021 - Sysadmins LV. All rights reserved