New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OCSP mode assumes only one CA cert, for the current issuer #3773
Comments
Ran into this today doing an OCSP Peer + OCSP Staple interop unit test. My OCSP Peer cert test tree has multiple intermediate CAs to rest revocation at both leaf and intermediate chainlinks. Basic assumption is that |
For OCSP Staple, challenge will be to correctly A) Choose the right cert (the leaf) out of a If A & B are right it still may not account for the Intermediate CA being revoked (i.e. Leaf not revoked, but it's CA is revoked by its issuer). |
OCSP Peer has an easier time with it because OCSP verification happens at runtime only when the external peer has passed TLS verification (trust chain) and OCSP verification can happen over a nicely ordered set of full chain(s). |
Fixed in branch tgb/issue-3773-on-ocsp-peer. After OCSP Peer PR merges, I will rebase on Dev and PR. Fixed local issuer determination is as follows:
Otherwise,
For [2] the ordering of certificates in the CA trust store does not matter as ordered chains are created. |
Resolves problems of [issue #3773](#3773). With this fix, NATS Server will locally determine it's own certificate's issuer from either the configured server certificate (bundle of leaf cert plus optional intermediate CA certs) or from the configured server CA trust store, as follows: 1. The operator may provide the server's certificate issuer in the second position of the server's certificate configuration (typically `cert_file` but may be `cert_store` on the Windows platform). If a candidate issuer is found here it is PKI validated as the actual issuer of the server's cert else a hard error. 2. If not found in [1], NATS Server will seek to create at least one verified chain with its configured trust store (typically `ca_file` but could by the system trust store if not configured). It will derive the issuer from the first verified chain. If no verified chain can be formed it is a hard error.
Fixed via #4355 |
Defect
Versions of
nats-server
and affected client libraries used:nats-server 2.9.11, nats-cli current HEAD
OS/Container environment:
FreeBSD Jail, but reproduces anywhere
Steps or code to reproduce the issue:
Have a TLS block with a
ca_file
with more than one cert in it, and setup an OCSP block.Expected result:
The server starts up, requests and obtains an OCSP staple, and I can query it.
Actual result:
If the
ca_file
bundle contains just one certificate, the intermediate used for issuing the current certificate, then things work. This is problematic, because at a bare minimum with a CA such as Let's Encrypt, you should be configuring both R3 and R4 (or E1 and E2) together, so that LE can fail-over to their stand-by. Theca_file
should be a list of all certificate authorities trusted for verifying peer identities, not a statement of which specific intermediate issued the current server certificate.If the
ca_file
contains a list of all the normal system CA certs, then with OCSP enabled the nats-server start-up errors out with:If the
ca_file
contains/etc/ssl/bundle-lets-encrypt.pem
which is a bundle of just the Let's Encrypt certs (E1, E2, R3, R4), then nats-server errors out with:which is OCSP-speak in this scenario for "sent the wrong cert details".
If I strip
ca_file
down to contain only the R3 certificate, then I get working OCSP; running the new natscli command:correctly yields:
The text was updated successfully, but these errors were encountered: