This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 97%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
Hi, I'm currently looking to implement Always On VPN and as this relies on certificates quite a bit I want to make sure things are good with our setup before proceeding.
The VPN server is off the domain (workgroup) and so is unable to perform the checks on CRL, etc. As these were set to LDAP #1, both our sub CAs had a HTTP entry at #2 but it didn't appear to be checking this. Reading a guide by Vadims it recommends putting HTTP first and suggesting removing LDAP entirely - I'm not sure if this is recommended in an existing CA deployment, or possibly just recreating so that HTTP is #1.
Anyway, I have adjusted the CDP and AIA on one sub-CA, removing LDAP, so HTTP is now #1 and this seems fine. More of the "certutil -verify" checks done on the VPN server appear to come back successful. However, it still outputs issues with our Root CA's CDP and AIA. I have fired up the Root CA and made the adjustments to the Extensions tab (removing LDAP and adding HTTP) and copied the new CRLs to the HTTP host. PKIVIEW still shows these as LDAP and I believe this is due to the lookup coming from the sub-CAs? Does this mean I need to renew the certificate on the sub-CAs for this change to take effect? Is this likely to have any impact to existing certificates issued to clients? In particular we currently use DirectAccess, which uses a device authentication certificate. The HTTP entry on the sub-CAs has existed for a couple of years, so I'm assuming they'd fall back to that ok? It's just the Root CA I'm not sure on, but I can always add LDAP entry back as #2.
I appreciate any help you can offer. Go easy on me, as this setup of CA has been configured long before I joined the company! :)
I'm not sure if this is recommended in an existing CA deployment, or possibly just recreating so that HTTP is #1.
it is still my recommendation. I believe you are referring to my article: Designing CRL Distribution Points and Authority Information Access locations. If you have configured both, LDAP and HTTP, then you clear checkboxes from LDAP URL which instruct CA to include the URL in certificates and CRLs, i.e.:
this is how checkboxes must be set for LDAP. This way CA will continue to publish CRLs there so existing certificates (that include LDAP URL) can download CRL from LDAP until they get replaced. No new certificate will contain LDAP, they will contain only HTTP.
However, it still outputs issues with our Root CA's CDP and AIA
you can solve this only be editing Root CA URLs and renewing your subordinate CA with new key pair.
PKIVIEW still shows these as LDAP
after updating URLs you have to revoke the most recent certificate based on "CA Exchange" certificate template and re-run the PKIView.msc.
Thanks for the information.
If the LDAP entry has been removed, is there an easy way to add it back in? I did try and it's greyed out on the publish options. I'm guessing this option is only selectable on file:// entries as AD will be protected? Not so much of an issue on the Root CA, as I have a snapshot before the entry was removed, but our sub-CAs have this entry missing.
I don't think I mentioned in my first post, but our Root CA is an offline root CA as well. I don't know if that makes any difference to things?
And just to confirm when you mention renewing the Sub-CAs with a new key pair - is this the prompt when selecting 'Renew CA certificate' to change the public and private key pair - I would select 'Yes'?
If the LDAP entry has been removed, is there an easy way to add it back in?
just insert same URL configuration string as it was before with proper variables. If you don't have a snapshot of SubCA, then you need to reverse-engineer the URL from existing certificates and replace pieces with variables. It isn't an easy task, though.
I did try and it's greyed out on the publish options.
make sure if LDAP URL prefix includes 3 slashes (i.e. "ldap:///")
I don't think I mentioned in my first post, but our Root CA is an offline root CA as well. I don't know if that makes any difference to things?
not much. The concept is the same: keep LDAP URL with modified checkbox setup and keep it published to AD without including it in certificates.
is this the prompt when selecting 'Renew CA certificate' to change the public and private key pair - I would select 'Yes'?
right.
Thanks, I didn't spot the third slash, so I've now been able to enter those back in to CDP and AIA.
One final question before pushing forward with renewing the sub-CAs, now that the LDAP entry is back, I've checked it against our backup and the publish options were not ticked anyway, I'm guessing because it's an offline CA. It does have three options ticked and I'm not sure if I should untick all of them. Below is a screenshot of our Root CA CDP comparison:
Should I leave the 'Include in all CRLs. Specifies where to publish in AD when publishing manually', as this seems to imply that if this isn't ticked and I attempt to run the dspublish command it will refuse to add it to AD?
Similar with the AIA:
You need to remove all LDAP URLs (from both, CDP and AIA extensions) from root CA, because you publish CRT and CRL files manually. For example, CRLs publishing command will be: certutil -dspublish -f RootCACrl.crl $RootCAHostName.
I did post a reply but somehow it's not gone through.
Thanks for your help. The certificates now look much cleaner and has now meant our Always On VPN system is able to do revocation checks on certs when a device connects.