I'm not sure if this is intended behavior or not but I've noticed a difference between using CertFromFile and CertFromMemory. The latter receives the certificate chain in reverse order due to differences in how TLS.credentialLoadX509Chain and TLS.credentialLoadX509ChainFromMemory construct the results. I don't know enough to know if the order is meant to matter in a certificate chain:
CertFromFile cert chainFiles key -> do
cred <- either error id <$> TLS.credentialLoadX509Chain cert chainFiles key
return $ TLS.Credentials [cred]
...
CertFromMemory certMemory chainCertsMemory keyMemory -> do
cred <-
either error return $
TLS.credentialLoadX509ChainFromMemory certMemory chainCertsMemory keyMemory
return $ TLS.Credentials [cred]
When using warp-tls's tlsSettings vs tlsSettingsMemory the first works where-as the latter results in curl and wget failing with:
curl: (35) OpenSSL/3.0.14: error:0A00007B:SSL routines::bad signature
Flipping the order of the certs in my "fullchain.pem" file manually allows tlsSettingsMemory to work as expected.
I'm not sure if this is intended behavior or not but I've noticed a difference between using
CertFromFile
andCertFromMemory
. The latter receives the certificate chain in reverse order due to differences in howTLS.credentialLoadX509Chain
andTLS.credentialLoadX509ChainFromMemory
construct the results. I don't know enough to know if the order is meant to matter in a certificate chain:When using warp-tls's
tlsSettings
vstlsSettingsMemory
the first works where-as the latter results in curl and wget failing with:curl: (35) OpenSSL/3.0.14: error:0A00007B:SSL routines::bad signature
Flipping the order of the certs in my "fullchain.pem" file manually allows
tlsSettingsMemory
to work as expected.