mirror of
https://github.com/opnsense/src.git
synced 2026-07-14 19:51:17 -04:00
42304ac845
Since the default store already points to /etc/ssl/certs and the CRLs are hashed there too it is trivial to bring libfetch applications to verifying the CRLs contained when doing a SSL connection. libfetch: ignore the error of an absence of a CRL ... when passing SSL_CRL_FILE / SSL_CRL_VERIFY. The situation isn't ideal, but since we don't know what we are going to deal with the situation is tricky. It's especially pointless in scenarios of pkg multi-repo cases where we need to deal wit a mixed bag of URLs during the same context. For the benefit of the doubt print the appropriate message for the user to see. In general it would be a bit safer if we could enforce the existence of a CRL distribution point as a mandatory CRL check and the others as an optional one with the warning as printed for the user to see. It would also need a strict mode if someone needed the other behaviour but since we did not have any consumers of SSL_CRL_FILE and --crl was broken for a long time it's safe to assume nobody uses this for these specific reasons. libfetch: add the error number to verify callback failure case libfetch: ignore leaf certificates in warning message #261 Make sure that only a CA without a CRL is being reported. 1. CRL verification takes places when provided. As OpenSSL assumes that hidden CRLs may exist but a distribution point is not mandatory there is no definitive truth about the matter. OpenSSL makes no effort to bridge this gap. 2. CRLs are anchored in the CA that is signing the certificate underneath so printing when that check fails because no CRL was provided is enough. |
||
|---|---|---|
| .. | ||
| common.c | ||
| common.h | ||
| fetch.3 | ||
| fetch.c | ||
| fetch.h | ||
| file.c | ||
| ftp.c | ||
| ftp.errors | ||
| http.c | ||
| http.errors | ||
| Makefile | ||
| Makefile.depend | ||
| Makefile.depend.options | ||