This is an issue with older OpenSSL versions - we’re running 1.0.2g in production (
) and encountered the same thing. Erlang depends on OpenSSL via libcrypto.so (at least on Ubuntu)
Long writeup here: https://calnetweb.berkeley.edu/calnet-technologists/incommon-sectigo-certificate-service/addtrust-external-root-expiration-may-2020
I fixed the same issue this morning with the Amplitude API. I couldn’t see a way of fixing it at our end, so I ended up switching to https://api2.amplitude.com, which they set up over the weekend with a simpler trust chain. More details here: https://status.amplitude.com
Modern browsers support this type of multiple trust chain, so I’d have expected Elixir/Erlang to too. Is there an issue being tracked somewhere?
If the webserver is IIS all you need to do is add a valid root and intermediate. Both of which expired same day.
https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA03l00000117LT has a write up and links to get the current root and intermidiate. Comodo shares a few roots with Sectigo.
use MMC on IIS server to add these accordingly.
If TomCat or java process you’ll need to update the PFX containing the cert, you may also need to update the cacerts of java 6, 1.6 and lower. Java 7 and 8 are good, java 6 should be good.
You can look in cacerts with keytool -list -keystore…
cd 'C:\Program Files (x86)\Java\jre1.8.0_181\bin'
((((.\keytool -list -keystore c:\captures\cacerts -storepass changeit) -join "`n") -replace "(?sim)(?:\S{2}$)","`$0`n|") -replace "`n",'').split('|') | ? {$_ -match 'fingerprint'} | ConvertFrom-Csv -header 'cacert','date','dateYr','cf','fingerprint' | where fingerprint -match "02:FA|ea:fa|f5:ad|2b:8f|a7:9e|d1:eb"
I don’t think it related to erlang’s :ssl (and http clients) - as far as i understand erlang uses it’s own code to process ssl stuff. Also, tried to update system to 1.1.1g just in case - no changes so far
Exactly. The :ssl application treats the certificates sent by the server as a linear, unbreakable chain, ignoring any self-signed certificates that may have been sent because of misconfiguration. (Recent versions do allow for servers that send the chain out-of-order). Chain validation then tries to find a root certificate in the trust store that matches the issuer of the last certificate in that chain (furthest from the end-certificate).
This approach is problematic with cross-signed certificates, as this example shows. Most other implementation treat the intermediate CA certificates sent by the server as a pool from which to draw missing elements in the chain, and they try multiple paths until a valid one is found.
The most reliable way to resolve this is to reconfigure the server to not send the cross-signing intermediate CA once the issuing root CA is invalidated. If the CA trust store used on the Erlang/Elixir side includes the (self-signed) equivalent root CA, then verification of the shorter chain will succeed.
There is no easy way to fix this on the client side in a generic way. A workaround for specific cases should be possible by passing a ‘partial chain fun’.
Actually it seems removing the expired root CA from the CA trust store seems to work, at least for some endpoints and some OTP versions. I don’t have time to dig into this further right now, but that’s something you may want to try…
Ah, I guess that’s the ssl_verify_fun package that’s used by Hackney (and therefore HTTPoison and, depending on configuration, Tesla) doing partial chain verification. It doesn’t fix the issue for applications that rely on :ssl standard verification, including Mint.
Discussion and workarounds for hackney based clients: SSL certificate expired issue · Issue #633 · benoitc/hackney · GitHub
There is a PR opened for erlang-certifi here: Remove expired AddTrust root CA by garthk · Pull Request #39 · certifi/erlang-certifi · GitHub
For Mint with CAStore, run mix deps.update castore: CAStore v0.1.6 removes the expired root CA, and the existing partial_chain hook in Mint does the rest.