Re: [exim/exim] [Bug]: GNUTLS certificate validation incompatible with certificates lacking a commonName attribute (Issue #3215)

@jgh ( https://code.exim.org/jgh ) wrote in #3215 (comment) ( https://code.exim.org/exim/exim/issues/3215#issuecomment-239517 ) :

> 
> 
> 
> You are configured to require that the server cert has a hostname which
> matches the peer you are talking to:
> 
> 
> 
> 16:02:59 702757 2a03:9800:10:246::2 in tls_verify_cert_hostnames? yes
> (matched "*")
> 
> 
> 
> The server cert seemingly has no name, neither SN nor SAN:
> 
>  0 s:                              
>    i:C = US, O = Let's Encrypt, CN =
> YE2
>    a:PKEY: id-ecPublicKey, 384 (bit); sigalg: ecdsa-with-SHA384
>   
> v:NotBefore: Apr 14 13:29:48 2026 GMT; NotAfter: Jul 13 13:29:47 2026 GMT
> 
> 
> Anybody could supply that cert; it will provide no assurance that you are
> talking to the peer you wanted to talk to, should you cease requiring the
> verification of hostname. You could, and happily be protected from casual
> third-party snooping by the TLS encryption; that will still work.
> 
> 
> 
> Or you could obtain a leaf cert for "pf" that has a SAN.
> 
> 

The certificate does have a matching SAN:

adam@adsbarratt:~$ (echo "QUIT"; sleep 5) | openssl s_client -connect pf.adam-barratt.org.uk:25 -starttls smtp -verify_quiet | openssl x509 -noout -ext subjectAltName
250 HELP
DONE
X509v3 Subject Alternative Name: critical
   DNS:pf.adam-barratt.org.uk
adam@adsbarratt:~$ 

So fat as I can tell from https://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_smtp_transport.html , that should be sufficient for tls_verify_cert_hostnames (which is on by default) to be happy.

---
View it on Exim Forgejo ( https://code.exim.org/exim/exim/issues/3215#issuecomment-239518 ) or reply to this email directly.