0

I am designing a cloud based PKI infrastructure which issues and manages TLS certificates for telemetry devices and data server. Each customer will install multiple telemetry devices and a data server in his/her premise. Data server collects telemetry data and also manages the devices (monitor status, SW update, etc). Certificate hierarchy will be like Root CA -> Region CA -> Customer CA -> Device/Server Certificate. Customer CA is an intermediate CA and every customer will have a different Cusmoter CA. Region CA is also intermediate which groups multiple customers based on geography (i.e LATAM, Europe, Asia-pacific, etc.). I am thinking to implement a segregation of trust between devices and server based on the customer they are associated with. In detail, a device belonging to one customer should not connect to server belonging to another customer and vice versa. I have two options in mind to implement this.

Use customer CA as trust anchor instead of Root CA. But revocation checking for Region CA won't be possible.

Add unique customer identifier in device/server certificate in the subject DN (Probably O or OU). But the verification can be done only at the application level whereas in option 1, the constraint is dealt by the TLS stack itself which is more secure.

Could someone recommend which implementation is more sensible and commonly followed?

Note: All CA certificates (RootCA, Region CA and Customer CA) are managed by the PKI infrastructure. Device/Server certificate generation/renewal/revocation happens through API request to the PKI server. Customers will have very limited role in certificate management.

Improve this question

2 Answers 2

Reset to default
1

First of all, the question you have not included is how to make a CA for customer A unable to sign a certificate for customer B (which may well be their competitor). This can be solved by hierarchically organising the devices, and using the nameConstraints extension.

So you could have Root CA that signs Region CA (nameConstraints:DNS:.latam.example.com), that signs Customer CA (pathLenConstraint:0, nameConstraints:DNS:.customer123.latam.example.com) that signs telemetrydevice99.customer123.latam.example.com

The unique customer identifier you mention would then be the sub-sub-domain.

Using the customer CA as trust anchor instead of Root CA would indeed work. Technically, you could provide a OCSP checking for Region CAs, although I'm dubious those would be checked by your TLS stack (even for end entities they aren't always verified). If you really end up with a compromised Region CA, that would still be a big issue for you (slightly less so than the Root CA, but only a bit), so you may need a software update to distrust the Region CA [and replace with a new one] anyway (beware that you don't end with a catch-22 with the CA and the update server).

Another strategy for "revocation" (actually an upper bound) would be to use relatively short expiration times for the Region CA (note that their children would need even shorter lifetimes) and periodically refresh them. This would ensure that the stack is able to cope with a changed CA (as this would not be a rare event), but you may discover some customers are not so connected/diligent as you would have expected.

Improve this answer
4
  • "you have not included is how to make a CA for customer A unable to sign a certificate for customer B (which may well be their competitor)" - This is a good question, but even if CA of customer A issued a certificate for customer B, this still doesn't matter, because devices of customer B check if the party being checked has a certificate issued by CA of customer B. This is the main point of the OP: Allow access only to those whose certificate was issued by a specific CA.
    – mentallurg
    Dec 26, 2022 at 14:36
  • @mentallurg I am answering this implicit question. It doesn't matter if the Customer CA is the one in the trust store but not if it's the OP Root CA
    – Ángel
    Dec 26, 2022 at 14:38
  • But the question who can issue certificates to whom does not matter at all. It is perfectly fine, if CA of customer A issues a certificate for a device/host of customer B. In the case described in OP it will just make no sense for devices of customer B to request a certificate from CA of customer A, because despite being absolutely valid and trusted, they will not allow the needed access, because access is based on the DN of the CA that issued the certificate.
    – mentallurg
    Dec 26, 2022 at 14:43
  • I apologize for the lack of clarity regarding certificate ownership/management. All CA certificates (RootCA, Region CA and Customer CA) are managed by me, which is, I own the corresponding private keys and I handle the certificate lifecycle. Device/Server certificate generation/renewal/revocation happens through API request to the cloud based PKI infrastructure I manage. I will update the question with this info.
    – Kumar
    Dec 28, 2022 at 4:43
0

If you want to use customer CA to do decide about access, it is fine.

Use customer CA as trust anchor instead of Root CA. But revocation checking for Region CA won't be possible.

When a certificate is validated, this includes check, if this certificate is not revoked. Also every certificate in the chain must be valid. Means, all certificates in the chain, including region CA and root CA, will be checked, if they are not revoked.

Improve this answer
7
  • 1
    If the trusted CA is the region CA, the root CA will not be used at all. And whether revocation of a CA found in trust store is going to be checked is probably dependent on the actual TLS stack.
    – Ángel
    Dec 26, 2022 at 13:58
  • @Ángel: You introduced new expression "trusted CA". The OP is not talking about trusted or not trusted CAs. The OP wants to limit access based on DN of the CA that issued certificate for particular party. And validation of any certificate includes validation of all certificates up the chain, starting from the certificate of the party that is asking for access, then certificate of its issuer CA, i.e. customer CA, then certificate of its issuer CA, i.e. region CA, then certificate of its issuer CA, i.e. root CA.
    – mentallurg
    Dec 26, 2022 at 14:30
  • I was treating it as two words: the CA that is trusted i.e. the CA you put in the trust store (on this comment I should have said Customer CA, not Region CA, though). If the CA you trust is the Customer CA, the chain ends there and upper signers are not checked (although I think some old openssl versions did due to a bug).
    – Ángel
    Dec 26, 2022 at 14:34
  • @Ángel: "CA you put in the trust store" - A) This is not needed; B) This would lead to problems with revocation; C) This is just unneeded effort.
    – mentallurg
    Dec 26, 2022 at 14:37
  • this doesn't seem a public purpose CA which may already be in whatever trust store the OP wants to use, so they will need to add it so this works
    – Ángel
    Dec 26, 2022 at 17:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .