From 23346a673fc703410172d6d282ed7ce646f60534 Mon Sep 17 00:00:00 2001 From: Gerard Snaauw Date: Thu, 12 Dec 2024 10:45:12 +0100 Subject: [PATCH] update documentation --- docs/pages/deployment/certificates.rst | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/docs/pages/deployment/certificates.rst b/docs/pages/deployment/certificates.rst index 91e537656..1be314f19 100644 --- a/docs/pages/deployment/certificates.rst +++ b/docs/pages/deployment/certificates.rst @@ -24,11 +24,6 @@ In ``did:x509`` the certificates are also used in the cryptographic proofs to ob This means the certificate chain now provides the root of trust and has stricter requirements than connection certificates. Trust in specific certificate CAs is configured per use-case in a :ref:`Discovery ` and :ref:`Policy ` definition file. -In addition, all trusted CA chains must also be added to the ``tls.truststorefile``. +All CA certificates from chains trusted per the above definition files are automatically added to the CRL checker at runtime. For certificate chains used in ``did:x509`` the Nuts-node always uses a hard-fail strategy, i.e., the ``pki.softfail`` config value is ignored during certificate validation for ``did:x509``. This means that the Nuts-node will not be able to verify a ``did:x509`` DID or Verifiable Credential signed by this DID Method if the CRL cannot be downloaded and the CRL in the cache is older than ``pki.maxupdatefailhours``. - -.. note:: - - Since the configured truststore file is now used for multiple purposes, it is no longer possible for the Nuts-node to determine what certificate chain is accepted/trusted for what purpose. - This means that all incoming TLS connections (including gRPC) must be offloaded in a proxy and validated against the expected certificate chain. \ No newline at end of file