You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Before Vault 1.11.0 , the root CA were not included in the chain, and I believe rightfully so.
Then the root CAs were added from a user’s request (#13489), and then removed again with a special option in #16935 . This was motivated by the concern raised in this comment #16057 (comment) , which were
Either they already have the root CA in their trust store, and don't need another copy of it - or they do not, in which case sending a self-signed certificate in the TLS handshake is not going to induce them to start trusting it
Sadly, the root CAs are still included by default in some endpoint without the possibility to remove them. To me it means that I must manually parse the CA chain, meaning adding a crypto dependency on the client side to do so, just to remove the Root CA(s). It's kind of frustrating because Vault has already the information of which CA is Root in the chain.
I know I could just send them over the wire and the Root CA will just be ignored, but that a waste of resources. Besides, with postquantum the certificates will be become much bigger, and we will want to squeeze every octet in order to fit the MTU.
Describe the solution you'd like
Please restore the old behavior, not sending the root CA(s), by adding the remove_roots_from_chain option to more endpoints.
The one that I see:
GET /pki/cert/:serial
GET /pki/cert/:serial/raw
GET /pki/cert/:serial/raw/pem
They are probably others
Describe alternatives you've considered
Manually parse the certificates at the level of the vault client.
The text was updated successfully, but these errors were encountered:
None of the endpoints you mention actually return a ca chain, just the individual certificate from storage along with revocation information.
I suppose you could be referring to the, GET /pki/cert/ca_chain API, but you could just use GET /pki/cert/ca instead if you have a simple root/intermediary CA setup.
Thank you for your quick answer! As stipulated in the note inside the API doc :
As of Vault 1.11.0, these endpoints return the full chain (including this certificate and all parent issuers known to Vault) in the ca_chain response, for both the certificate and newer ca_chain fields. The root certificate is no longer elided
What I observe using the API is that is indeed the whole CA chain (including root) is included inside the certificate field. This field is a string containing the concatenation of the whole CA chain + the certificate.
And so even for the endpoint taking serial as parameters.
Is your feature request related to a problem? Please describe.
Before Vault 1.11.0 , the root CA were not included in the chain, and I believe rightfully so.
Then the root CAs were added from a user’s request (#13489), and then removed again with a special option in #16935 . This was motivated by the concern raised in this comment #16057 (comment) , which were
Sadly, the root CAs are still included by default in some endpoint without the possibility to remove them. To me it means that I must manually parse the CA chain, meaning adding a crypto dependency on the client side to do so, just to remove the Root CA(s). It's kind of frustrating because Vault has already the information of which CA is Root in the chain.
I know I could just send them over the wire and the Root CA will just be ignored, but that a waste of resources. Besides, with postquantum the certificates will be become much bigger, and we will want to squeeze every octet in order to fit the MTU.
Describe the solution you'd like
Please restore the old behavior, not sending the root CA(s), by adding the
remove_roots_from_chain
option to more endpoints.The one that I see:
They are probably others
Describe alternatives you've considered
Manually parse the certificates at the level of the vault client.
The text was updated successfully, but these errors were encountered: