[doc] Split peer and root CA for trusted certificates; Add purpose #6792
Conversation
minglumlu
changed the title
|
The doc |
| | Trusted root CA for \<PURPOSE\>| /etc/stunnel/certs-ca-\<PURPOSE\>/ | no (derived from the \<PURPOSE\>) | Root CA certificates that users have installed to validate the server certificate for \<PURPOSE\> | ||
| | Trusted peer for \<PURPOSE\>| /etc/stunnel/certs-peer-\<PURPOSE\>/ | no (derived from the \<PURPOSE\>) | Peer certificates that users have installed to validate the server certificate for \<PURPOSE\> |
There was a problem hiding this comment.
The first directory is user-configurable, through the API, as per the new use-case (the user needs to configure the root before trusting anything)
The second one, because it relies on certificate pinning, I think it shouldn't and the API for users to control them should be removed. If this doesn't ring true, then I think more explanations should be added to understand the threat model this meant to protect against to understand what's needed or not.
There was a problem hiding this comment.
I understand the locations of individual certificates are internal info of XAPI; and the bundle locations need to be known by local TLS communication endpoints.
I can't see the use case of letting the locations configurable by users.
There was a problem hiding this comment.
But installing certificates for a purpose is being able to configure the certificates, at least from what is presented in the table
There was a problem hiding this comment.
I've not get the point. Please bear with me. But the full path of the store in the filesystem is determined by XAPI. Only a part of it is determined by the purpose received from the API. Say, the purpose is for wlb; licensing, the certificates with this purpose will be stored under /etc/trusted-certs/ca-wlb/name1.pem or /etc/trusted-certs/peer-wlb/name1.pem and /etc/trusted-certs/ca-licensing/name1.pem or /etc/trusted-certs/peer-licensing/name1.pem.
The corresponding bundles would be:
/etc/trusted-certs/peer-bundle-wlb.pem or /etc/trusted-certs/peer-bundle-wlb.pem and
/etc/trusted-certs/peer-bundle-licensing.pem or /etc/trusted-certs/peer-bundle-licensing.pem.
There was a problem hiding this comment.
I see where the misunderstanding comes from:
I have to be clear that:
- Users are not meant to change the certificate files at all, not a single one of the certificates, even if in the table it say they can be configured
- The only way to configure a certificate is using the API.
- Certificates that can be installed, or removed using the API are considered to be configurable.
- There are some certificates that the users are never meant to be aware of, these are considered to not be configurable.
There was a problem hiding this comment.
The second one, because it relies on certificate pinning, I think it shouldn't and the API for users to control them should be removed.
The idea is actually to let users directly install "pinned" certificates.
An alternative, which might be what you are thinking of, would be to indirectly install them through other calls. For example a call that configures the address of the WLB or license server would take the certificate as a new parameter.
| This means that the TLS clients need to only trust the user-installed certificates when establishing a TLS connection for a specific purpose. Conversely pool connections will ignore these certificates. | ||
| Two kinds of trusted certificates can be supported when validating a server certificate, which also represent two validation modes: | ||
| * root CA certificate, which is used in standard PKI validation where the server’s certificate chain is built with it; | ||
| * peer certificate, which represents the expected server leaf certificate and hence can be used to compare with the received server leaf certificate. This model supports quick trust establishment, including Trust‑On‑First‑Use (TOFU) and self-signed server certificate scenarios where the first received leaf certificate is trusted to avoid user intervention or configuration. |
There was a problem hiding this comment.
Is this describing certificate pinning? It would be good to mention it in name if it's that. Or describe how to differs.
There was a problem hiding this comment.
Good to know the "certificate pinning" which seems a common used phrase. Thanks.
| * Pool.uninstall_ca_certificate: rename of Pool.certificate_uninstall, removes the certificate from the database. | ||
| * Host.reset_server_certificate: replaces Host.emergency_reset_server_certificate, now it's allowed for role _R_POOL_ADMIN. It adds a record for the generated Default Certificate to the database while removing the previous record, if any. | ||
| * Pool.rotate_internal_certificates: This call generates new Pool certificates, and substitutes the previous certificates with these. See the certificate expiry section for more details. | ||
| * Pool.install_peer_certificate: adds the peer certificate to the database. |
There was a problem hiding this comment.
It's not clear to me how is the "purpose" injected in these RPC calls, or how are the root certificate modified to make use of it.
Why isn't the WLB being used as a reason as well, for example?
There was a problem hiding this comment.
I added the argument list for this.
There was a problem hiding this comment.
Why isn't the WLB being used as a reason as well, for example?
Yeah. WLB is a use case as well. WLB supports both CA signed certificates and self-signed certificates. The "purpose" can be extended with such as "wlb" as well.
I describe two approaches for the validation: certificate chain validation and certificate pinning. The bundles are updated separately now.
Signed-off-by: Ming Lu <[email protected]>
minglumlu
force-pushed
the
private/mingl/CP-310088
branch
from
d6a4b85 to
08d29ff
Compare
|
|
||
| * A new enumeration type "purpose" is introduced to indicate the intended usage of a trusted certificate. | ||
| A new *Certificate* class field "purposes" (a set of values of enumeration type "purpose") will be added to represent all applicable purposes of a trusted certificate. | ||
| By default, this set is empty which corresponds to the existing general "ca" certificates. |
There was a problem hiding this comment.
I.e. an empty set implies "all" purposes?
| The new "peer" will represent trusted peer certificates. | ||
|
|
||
| * A new enumeration type "purpose" is introduced to indicate the intended usage of a trusted certificate. | ||
| A new *Certificate* class field "purposes" (a set of values of enumeration type "purpose") will be added to represent all applicable purposes of a trusted certificate. |
There was a problem hiding this comment.
I'd probably use the singular word purpose here and in the parameters below.
| | Pool Bundle | /etc/stunnel/xapi-pool-ca-bundle.pem | no | Bundle of certificates that hosts use to verify other hosts on pool communications, this is kept in sync with "Trusted Pool" | ||
|
|
||
| For backwards compatibility, when a trusted certificate is being installed via "pool.install_ca_certificate" or "pool.install_peer_certificate" but with empty "purposes", | ||
| the trusted certificate will be stored as "Trusted Default" and "Default Bundle". |
There was a problem hiding this comment.
But if you mix CA and peer certificates, then it is not clear which verification mode needs to be used (verifying the chain + hostname vs. just the peer cert). Should we not have a separate default bundle for peer certificates?
There was a problem hiding this comment.
Or perhaps we should not allow peer certificates without "purpose"?
|
I think we should make the general precedence rules clear in this document: when xapi makes an external connection, then there may be multiple "matching" trusted certificate bundles and it must unambiguously choose one to verify the remote against. This could be resolved, for example, by searching for a certificate bundle in this order:
(insert "3. A peer-certificate bundle with any purpose" if we allow that) |
3 participants
Uh oh!
There was an error while loading. Please reload this page.