Make tests robust to non-AES ciphersuites

[jdtw]

I was a bit late to chime in with a review before this got merged.
One other source of test failures was the assumption of AES_128_GCM_SHA256 being selected by both the httptest spawned TLS server and the unit test TLS client.

Go alters the default ciphersuite to prefer ChaPoly over AES-GCM suites if the underlying hardware doesn't have AES extensions. (https://cs.opensource.google/go/go/+/master:src/crypto/tls/handshake_server_tls13.go;l=158?q=defaultCipherSuitesTLS13NoAES%20&ss=go%2Fgo). So CI/CD systems running under virtualization may not always reflect the underlying CPUs extensions. One good example—and how I ended up debugging this issue—was NixOS CI system for Darwin x86-64 wasn't picking AES. Temporarily I ended up disabling tests on darwin-x86_64.

So the lines 110 and 138 for expectedConnect string in TestConnect trying to match Cipher Suite: AES_128_GCM_SHA256 cipher will continue causing test failures where Go cannot deduce presence of hardware acceleration for AES.

Originally posted by @bdd in #265 (comment)

[jdtw]

Hardcoding TLS 1.3 is also fragile.

[bdd]

Hardcoding TLS 1.3 is also fragile.

Certigo requires at least Go 1.13.
Go added TLS 1.3 support in 1.12 as opt-in and promoted it to on-by-default in 1.13.
Go always chooses MaxVersion. Due to the nature of the unit test, the server and the client are instantiated in the same process. So as long as there's no TLS 1.4 in Go, you're good. That's gonna take long years to land :)

[jdtw]

Yeah, I was imaging TLS 1.4 :). But those 20 year certs in the test will probably expire before then...