Revert "Revert "feat: add ssl opt to httpc by default"" #703
Conversation
This reverts commit a8ab602.
TLS: raise limit on max intermediate certs to same as OpenSSL Prevents validation error for endpoints presenting a longer certificate chain. Reference: * https://docs.openssl.org/3.3/man3/SSL_CTX_set_verify/#notes
|
Well CRL checking is fairly complex. And from the OTP ssl applications point of view we can not tell you who trust. From the httpc applications point of view there can be some default trust for web-applications. There is no "one way" of building a CRL cache, and it can depend on how the certificate authorities set things up. Certificates may include distribution points that will include URIs to get CRL's usually plain HTTP or LDAP ones. CRL's can also be provided in PEM-files (that also must be obtained somehow). Now as CRL checks are done during certificate path validation so you want to cache the CRL's to not have to fetch them every time. Although CRL's can become very large so might not want to cache them uncontrollably, and this is why the default cache at the moment does not cache. We have a plan to change that, and PR are always welcome. Certificate revocation check can have three outcomes, it has found that a certificate is valid, invalid, or it was not able to determine it because the available CRL's did not cover the certificate you where trying to check. The best effort option possible make a connection not fail if CRL-server is down for instance, but it would also pass certificates that do not have a CRL reference. We provide an API ( https://www.erlang.org/doc/apps/ssl/ssl_crl_cache_api.html) to plug your own cache handling as there might be many application dependent circumstances on how to implement the cache and make tradeoffs for it freshness. When it comes to httpc (in inets application) there are many legacy reasons how it came about, and frankly it has for several reasons not had top priority, I think it has shaped up but we still have ambitions to make it better given that we get priority and resources needed to do so. |
|
I have taken the stand that I firmly believe that this should be fixed upstream in OTP itself. I can not ensure that I will not break some codebase that may rely on the existing setup. Thank y'all! |
Reverts #702