When creating a vanilla Kubernetes Ingress or a Traefik IngressRoute with a TLS secret configured to do termination, I find that attempting to curl or visit them on a browser I get errors like:
SSL_ERROR_NO_CYPHER_OVERLAP in Firefoxcurl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure in curlbut only for the first few minutes of their existence. After that, they function as expected.
Upon further inspection using openssl:
> openssl s_client -showcerts -servername [SERVER NAME] -connect [SERVER NAME]:443
CONNECTED(00000006)
8044535936:error:1404B410:SSL routines:ST_CONNECT:sslv3 alert handshake failure:/AppleInternal/Library/BuildRoots/d9889869-120b-11ee-b796-7a03568b17ac/Library/Caches/com.apple.xbs/Sources/libressl/libressl-3.3/ssl/tls13_lib.c:129:SSL alert number 40
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 349 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.3
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Start Time: 1694429705
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
It seems no cyphers are returned at all. Why is this?
I expect that upon creating these ingresses, some controller will immediately choose sensible defaults if not specified (which in this case, they are not). Nginx (the standalone reverse proxy software, not the Kubernetes ingress class which I have not tried) has no such problem, and is able to do this immediately.
It turns out this happened because I was using Cloudflare with 'Universal SSL' enabled - it was taking some time for Cloudflare to acquire the certificates from Let's Encrypt/Google Trust Services. Immediately trying to query them before the certificate could be issued resulted in a connection failure.