0

Planning a two tier ADCS PKI infrastructure as follows:

              ORCA
   ____________|____________
  |            |            |
 SCA1         SCA2        SCA3
one.int      two.int    three.int

Where ORCA is an offline root CA, and SCA1..SCA3 are subordinate CAs where each subordinate CA belongs to to a completely different domain/forest with no trust or knowledge of one another (one.int, two.int, three.int)

Now bearing in mind this is ADCS the ideal scenario is that the ORCA is configured with a LDAP URL for CRLs as well as a HTTP URL. Domain clients would then get the ORCA's CRL from LDAP and non-domain clients would get it from the HTTP location, presumably a server running IIS or something.

However, this is a problem when multiple completely separate domains all use the same root - when the ORCA is configured it asks for a distinguished name and any issued CRLs with a LDAP URL in it will contain exactly that distinguished name.

So if we set the ORCA's DN to DC=one,DC=int all CRLs issued by ORCA will contain LDAP://<lots of stuff that don't matter>,DC=one,DC=int. So now the clients from two.int and three.int would be trying to go over to one.int to get the CRL from LDAP there - yet they don't even know of the existence of the other domains/forests.

And if we try to take an ORCA CRL that contains LDAP://...,Dc=one,DC=int and manually publish it to two.int ... I'll get an error that one.int was not found.

We could remove all LDAP URLs from the ORCA CRL and only have a HTTP URL there, but the (other) advantage that publishing to LDAP gives is "automatic" redundancy and load balancing (in the sense that you never have a domain with a single DC). Giving a HTTP URL would mean that we would need a web server cluster to ensure high availability at the very least, but it also means a construct would look somewhat like this:

              ORCA
               |
          IIS CLORCA
   ____________|____________
  |            |            |
 SCA1         SCA2        SCA3
one.int      two.int    three.int
IIS CL1      IIS CL2     IIS CL3

Where each of the IIS CLs are IIS clusters: IIS CLORCA just the CRL for ORCA (and runs OCSP?), IIS CL1 hosts the CRL + delta for SCA1 and runs OCSP, etc etc...

Of course on the side of the SCA1..SCA3 you could combine the CA role with the IIS role but would you really want to do that? That's a rubbish idea from a security point of view and increases the attack surface of the CA itself.

Of course in this construct each subordinate CA would publish to LDAP, but all of the domains have clients that are not part of the domain either so HTTP URL is required and makes no sense to have a single server serving serving the CRL/delta + OCSP. If that server happens to be offline when a non-domain client tries to validate a certificate - like it will happen at least once a month with Windows Updates -, the client will receive no reply from OSCP nor be able to download a CRL and therefore fail to validate the certificate. Hence the reason for IIS clusters on each individual domain.

Yet ... this feels over the top. I wanted to get people's opinions bearing in mind that the purpose of this is for a production environment.

0

I would go with HTTP-only URLs. The only benefit with LDAP is redundancy and nothing else. Also, redundancy is orginized only between global catalogs, not all domain controllers.

HTTP supports E-tag and Max-Age headers. And Windows CryptoAPI client (at least) supports them to improve revocation checking experience. You can check my blog post on this subject in details: Designing CRL Distribution Points and Authority Information Access locations

You mentioned security risk when CRLs are hosted on a common IIS. There is no much security risk as long as IIS owners have possession of existence of all three forests. Also, IIS will make CRL separation by creating a separate web site for each forest. The only thing is they share -- same hardware at web server. Nothing else. In cloud solutions it is pretty common, when you share same hardware with other customers you are not aware of. domain part in URLs will be unique, you can purchase enough IP addresses to make websites completely irrelated.

one.int is now able to ask the OCSP that's domain agnostic to validate a cert from two.int

one.int is able to ask the OCSP only if one.int gets a certtificate from two.int. And it doesn't matter if CRLs are hosted on a common web server or separate web servers. I don't clearly understand the security/privacy issue if revocation information is accessible from internet.

  • Thx for the answer, the blog is really useful. But I feel like it doesn't answer a lot of my (albeit indirect) questions: as it is presented it sounds like you're saying my 2nd diagram is the way to go. That implies 4 clusters for web servers and even if we assume 2 nodes per cluster that's 8 machines total. Feels like a lot. Now I can see that as a way of reducing this we can either have the subordinate CAs issuing their CRLs to the domain agnostic IIS cluster at the top (although I feel like this breaks security because one.int can find out which certificates were revoked on two.int) – JonU Apr 10 at 10:34
  • Or another option is to remove the top cluster and use some DNS trickery: set the URL as something like http://pkiserv/<something> where pkiserv is not a FQDN and each individual domain's DNS lists a separate address for pkiserv - you're on one.int? Then pkiserv resolves to 10.0.0.1. two.int? then 10.0.0.2... etc Feels like a cheap trick with a lot of moving parts that can go wrong, but on the other hand 8 machines for 1 root and 3 subordinate CAs feels excessive (excluding the actual CAs ofc) – JonU Apr 10 at 10:37
  • I feel like this breaks security because one.int can find out which certificates were revoked on two.int -- CRL doesn't include any sensitive data, so they barely break any security. CRLs only include serial numbers. You can't recover actual revoked certificate just from serial number. I would recommend a common IIS cluster with load balancing. – Crypt32 Apr 10 at 10:52
  • Breaks security in the sense that you now have one IIS (cluster) hosting CRLs for 3 domains that are meant to know nothing about one another. It doesn't mean security at a PKI level but, to an extent at least, removes the separation layer between the domains. Assuming that an OCSP would also be installed, one.int is now able to ask the OCSP that's domain agnostic to validate a cert from two.int - and it would get a reply! Maybe breaking security is not the best way to describe it, but removes a layer of separation that exists between the domains. – JonU Apr 10 at 10:57
  • Also please in the name of anyone that reads your blog at work, can you please remove the link to Tera Patrick's website from the blog post above? Being completely oblivious as to whom Tera Patrick is I just learned the hard way -- seeing it for myself. And this while at work. Not nice. – JonU Apr 10 at 10:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.