Root CA certificates used by the mentioned sites (Comodo and USERTrust) have expired this morning (UTC time). While I find it remarkable that two different Root CA certs would expire at the exact same second, this may be explained by USERTrust being affiliated with Comodo (now Sectigo).
Edit: These two actually never were Root CA certificates, but rather intermediate CAs signed by "AddTrust External CA Root". Therefore, their expiration date was determined by the validity of the "AddTrust External CA Root" certificate, which also happens to have expired at the exact same second.
Now, updated certificates (sharing their private keys with the expired ones) have been issued back in 2010 (Comodo, USERTrust). These certificates are part of the common Root CA stores these days (including Apple's system trust store), therefore browsers establish the connections perfectly fine. The same is true for most variants of cURL (e.g. from MacPorts or Homebrew), which are built against custom OpenSSL installations.
The built-in cURL variant of macOS 10.14 is built against LibreSSL and uses
/etc/ssl/cert.pem as its Root CA store, which also includes the new certificates. However, something appears to causing cURL or LibreSSL to prefer the old certificates for its validity check. I suppose cURL is at least somewhat involved in the problem, since I couldn't get the connections to fail using
/usr/bin/openssl s_client (
/usr/bin/openssl is actually built from LibreSSL).
My hypothesis would be that the problem is caused by the sites sending the expired Root CA certificate as part of their certificate chain. Including the Root CA in such chains is allowed, but not required, and in this case appears to break certificate validation.
Edit: This is part of a series of issues around the "AddTrust External CA Root" expiration. See this blog post by Andrew Ayer or this Twitter thread by Ryan Sleevi for the bigger picture. Ryan Sleevi also has a collection of things failing due to the expiration.
On macOS 10.15, where cURL uses OpenSSL 0.9.8 by default, the issue apparently may be mitigated by setting the environment variable
CURL_SSL_BACKEND=secure-transport. This does not work on 10.14 with its LibreSSL which, according to Christian Heimes, is affected by the issue in general.