| Re: [hono-dev] Questions regarding Certificate Based Authentication in Hono |
|
Your assessment is correct. But this only means that you cannot use device certificates that have been signed by a public CA directly. You will always need to use an intermediate CA for signing your device certificates. However, I do not see this as a limitation because this is what you will want to do anyway in order to have better control over the validity of your device certificates, e.g. revoking the intermediate CA cert in order to invalidate all devices. You can only do that if you are in control of the intermediate CA yourself.
The most common use case FMPOV will be to use a self signed root CA for your devices anyway. I cannot see an advantage in using (expensive) public certificates for the devices ... From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> on behalf of Poehn Sebastian (INST/ECS4) <Sebastian.Poehn@xxxxxxxxxxxx>
Sent: Tuesday, May 22, 2018 14:30 To: hono developer discussions Subject: Re: [hono-dev] Questions regarding Certificate Based Authentication in Hono Having thought over this on Sunday, there is now one more question that came up to my mind:
To my understanding the subject-dn of the trusted-ca must be unique within a Hono installation. I understand that this makes the validation process straight-forward. Unfortunatelly I see that this makes trouble in installations with multiple tenants: * A user runs one CA to generate device certificates but wants to split them over multiple tenants. * A user ordered device certificates from a public CA. Another user now orders certificates from the same CA. In both cases the uniqueness criteria of Tenant API would reject the subject-dn of the second tenant. -----Original Message----- From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> On Behalf Of Poehn Sebastian (INST/ECS4) Sent: Montag, 14. Mai 2018 18:01 To: hono developer discussions <hono-dev@xxxxxxxxxxx> Subject: Re: [hono-dev] Questions regarding Certificate Based Authentication in Hono Thanks for that prompt reply. >> In addition I have some advanced questions: >> * As of now trusted-ca contains one certificate. How can an expiry of >> the CA certificate be handled (as one would like to rotate the public key too)? > >Currently, that is not possible. We will need to allow for the configuration of multiple root CA certs, having the same subject DN but different (overlapping) validity periods. The protocol adapters should then get all (currently) valid public keys for validating the device's client certificate in the TLS handshake. That sounds like a good approach to me. And the additional benefit would be that if this information is present in the tenant object, one could build some functionality that checks for upcoming expiry of certificates. >> * Is it required to import the CA certificates to the Java trust >> store in addition to the tenant API? > >No, that is not necessary. In particular, it is not necessary to restart the protocol adapters in order to enable client cert based auth for a tenant. >> * Is it possible to use a sub CA for the trusted-ca if a certificate >> hierarchy with multiple CAs is used (e.g. Root CA <-> Sub CA A <-> >> Sub CA A1 <-> Device) > >I am not sure if I understand the question. For your example to work, you will need to register Sub CA A1 as the trusted root CA certificate for the tenant. Yes, that was my intention. By the way, this will be another use-case for the multi trusted-ca feature. Then one could just add the CA A2, CA B1 and CA B2 in addition for this tenant. >> * What about certificates contained in the Java trust store? Is it >> possible to omit the public-key for those? > >If the question is if you can also device certificates that have been signed by one of the standard root CAs contained in the Java key store, then the answer is: >No. > >But I also do not see the use case for it as it would require that every tenant uses device certs signed by a different standard root CA ... Yes, totally agree with you. _______________________________________________ hono-dev mailing list hono-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/hono-dev _______________________________________________ hono-dev mailing list hono-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/hono-dev |