https client using Let's Encrypt certs throws error

[Edward Johnstone]

Has this been discussed previously?
In the following example, downloading the certs in pem format and placing them in /flash/cert/ca.pem works on sites such as www.google.com, www.example.org, but not a web server using Let's Encrypt certs.
In my case I am using the GPy board with the Pytrack v2 board, with all of the latest firmware updates.

import time
import socket
import ssl
from network import LTE
import machine

HOST = "some-another.server.net" # Let's Encrypt certs - does not work
#HOST = "www.google.com" # works
#HOST = "www.example.org" # works

lte = LTE()
lte.attach()
print("attaching..",end='')
while not lte.isattached():
    time.sleep(0.25)

    print('.',end='')
    print(lte.send_at_cmd('AT!="fsm"'))         # get the System FSM
print("attached!")

lte.connect()
print("connecting [##",end='')
while not lte.isconnected():
    time.sleep(0.25)
    print('#',end='')
    #print(lte.send_at_cmd('AT!="showphy"'))
    print(lte.send_at_cmd('AT!="fsm"'))
print("] connected!")

s = socket.socket()

ai = socket.getaddrinfo('{}'.format(HOST), 443)
addr = ai[0][-1]

#ss = ssl.wrap_socket(s)
ss = ssl.wrap_socket(s, cert_reqs=ssl.CERT_REQUIRED, ca_certs='/flash/cert/ca.pem')
ss.connect(addr)

# Exception OSError -9984 thrown here
#    if ca.pem came from a site using Let's Encrypt Certs
print('certs accepted: add the rest of the code here')

[jcaron]

@Edward-Johnstone Do you have the associated logs/traces?

Do you have an example of the relevant certificate?

Just to clarify, you are downloading the site certificate itself, and placing it in ca.pem? Or the full chain? Or the root? If the site certificate itself, this will be even more difficult to maintain for Let's Encrypt certs than for others due to the short expiration time (3 months), which means you'll have to update the list constantly. It is usually a better idea to include the (relevant) root certs rather than the site certificate itself.

Also note that Let's Encrypt had their previous root cert expire recently. This has led to quite some complications, as by default they continue to issue certs which are signed both by a (new) valid root and by an expired one (for older Android versions). Some TLS implementation balk at this and reject the cert even though it is signed by a recognised valid cert. Not sure whether the implementation here will have an issue with that or not.

[jcaron]

@Edward-Johnstone said in https client using Let's Encrypt certs throws error:

OSError -9984

Additional info, -9984 is -0x2700 which is MBEDTLS_ERR_X509_CERT_VERIFY_FAILED. There are additional MBEDTLS_X509_BADCERT_*flags which go with it giving more details, but they're probably lost on the way somewhere.

[Edward Johnstone]

@jcaron thanks for responding..... I've been using the full chain, for google, example.org and my site. Good point about the short expiration date. Let me try the root certs on all three sites and see if that works.
Note: to get the ca.pem, I've navigated to these sites in a browser, and followed the link to the certs from the icon to the left of the URL and downloaded the full chain. This worked for google and example.org.
And, thanks for explaining the error codes.

[Edward Johnstone]

@Edward-Johnstone Next day ....
... next day ..
I tried the root certs alone as you suggested, not the chain, in ca.pem for google.com and example.org, which are GlobalSign Root CA and DigiCert Global Root CA respectively. These two, in fact, worked! The root cert for my site using Let's Encrypt, which is ISRG Root X1, did not work, giving the same error as described above.
Conclusion: as you suggested there is something amiss with Let's Encrypt's Root cert : (
Thanks again.

[jcaron]

@Edward-Johnstone if you have control over the server, there’s an option (which works only in recent versions of cert bot and other similar tools) to request a certificate without the additional expired cert used for old Android compatibility. You may try that and see if that improves things. Or just remove the last certificate in the chain which gives the same effect (but will need to be done every time the LE cert is renewed). Only if the chain includes the offending cert, of course.

[Edward Johnstone]

@jcaron For completeness sake, let me post here running this script, using the 3 Root Certs. A few notes:

• one can concatenate the Root CA
• the order of the Root CA doesn't matter (not shown, but it's true)
• the Root CA were obtained following the lock icon link in the browser
• only the Root CA was used, by clicking on the link PEM (cert) and then concatenated into one file
• and then lastly success and failure

$ ./pyboard.py -f cp GlobalSign_DigiCert_ISRG.pem :cert/ca.pem
cp GlobalSign_DigiCert_ISRG.pem :cert/ca.pem

$ ./pyboard.py -f cat :cert/ca.pem
cat :cert/ca.pem
-----BEGIN CERTIFICATE-----
MIIDdTCCAl2gAwIBAgILBAAAAAABFUtaw5QwDQYJKoZIhvcNAQEFBQAwVzELMAkG
A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jv
b3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05ODA5MDExMjAw
MDBaFw0yODAxMjgxMjAwMDBaMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i
YWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT
aWduIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaDuaZ
jc6j40+Kfvvxi4Mla+pIH/EqsLmVEQS98GPR4mdmzxzdzxtIK+6NiY6arymAZavp
xy0Sy6scTHAHoT0KMM0VjU/43dSMUBUc71DuxC73/OlS8pF94G3VNTCOXkNz8kHp
1Wrjsok6Vjk4bwY8iGlbKk3Fp1S4bInMm/k8yuX9ifUSPJJ4ltbcdG6TRGHRjcdG
snUOhugZitVtbNV4FpWi6cgKOOvyJBNPc1STE4U6G7weNLWLBYy5d4ux2x8gkasJ
U26Qzns3dLlwR5EiUWMWea6xrkEmCMgZK9FGqkjWZCrXgzT/LCrBbBlDSgeF59N8
9iFo7+ryUp9/k5DPAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E
BTADAQH/MB0GA1UdDgQWBBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0B
AQUFAAOCAQEA1nPnfE920I2/7LqivjTFKDK1fPxsnCwrvQmeU79rXqoRSLblCKOz
yj1hTdNGCbM+w6DjY1Ub8rrvrTnhQ7k4o+YviiY776BQVvnGCv04zcQLcFGUl5gE
38NflNUVyRRBnMRddWQVDf9VMOyGj/8N7yy5Y0b2qvzfvGn9LhJIZJrglfCm7ymP
AbEVtQwdpf5pLGkkeB6zpxxxYu7KyJesF12KwvhHhm4qxFYxldBniYUr+WymXUad
DKqC5JlR3XC321Y9YeRq4VzW9v493kHMB65jUr9TU/Qr6cf9tveCX4XSQRjbgbME
HMUfpIBvFSDJ3gyICh3WZlXi/EjJKSZp4A==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIDrzCCApegAwIBAgIQCDvgVpBCRrGhdWrJWZHHSjANBgkqhkiG9w0BAQUFADBh
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSAwHgYDVQQDExdEaWdpQ2VydCBHbG9iYWwgUm9vdCBD
QTAeFw0wNjExMTAwMDAwMDBaFw0zMTExMTAwMDAwMDBaMGExCzAJBgNVBAYTAlVT
MRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j
b20xIDAeBgNVBAMTF0RpZ2lDZXJ0IEdsb2JhbCBSb290IENBMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4jvhEXLeqKTTo1eqUKKPC3eQyaKl7hLOllsB
CSDMAZOnTjC3U/dDxGkAV53ijSLdhwZAAIEJzs4bg7/fzTtxRuLWZscFs3YnFo97
nh6Vfe63SKMI2tavegw5BmV/Sl0fvBf4q77uKNd0f3p4mVmFaG5cIzJLv07A6Fpt
43C/dxC//AH2hdmoRBBYMql1GNXRor5H4idq9Joz+EkIYIvUX7Q6hL+hqkpMfT7P
T19sdl6gSzeRntwi5m3OFBqOasv+zbMUZBfHWymeMr/y7vrTC0LUq7dBMtoM1O/4
gdW7jVg/tRvoSSiicNoxBN33shbyTApOB6jtSj1etX+jkMOvJwIDAQABo2MwYTAO
BgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUA95QNVbR
TLtm8KPiGxvDl7I90VUwHwYDVR0jBBgwFoAUA95QNVbRTLtm8KPiGxvDl7I90VUw
DQYJKoZIhvcNAQEFBQADggEBAMucN6pIExIK+t1EnE9SsPTfrgT1eXkIoyQY/Esr
hMAtudXH/vTBH1jLuG2cenTnmCmrEbXjcKChzUyImZOMkXDiqw8cvpOp/2PV5Adg
06O/nVsJ8dWO41P0jmP6P6fbtGbfYmbW0W5BjfIttep3Sp+dWOIrWcBAI+0tKIJF
PnlUkiaY4IBIqDfv8NZ5YBberOgOzW6sRBc4L0na4UU+Krk2U886UAb3LujEV0ls
YSEY1QSteDwsOoBrp+uvFRTp2InBuThs4pFsiv9kuXclVzDAGySj4dzp30d8tbQk
CAUw7C29C79Fv1C5qfPrmAESrciIxpg0X40KPMbp1ZWVbd4=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMTUwNjA0MTEwNDM4
WhcNMzUwNjA0MTEwNDM4WjBPMQswCQYDVQQGEwJVUzEpMCcGA1UEChMgSW50ZXJu
ZXQgU2VjdXJpdHkgUmVzZWFyY2ggR3JvdXAxFTATBgNVBAMTDElTUkcgUm9vdCBY
MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAK3oJHP0FDfzm54rVygc
h77ct984kIxuPOZXoHj3dcKi/vVqbvYATyjb3miGbESTtrFj/RQSa78f0uoxmyF+
0TM8ukj13Xnfs7j/EvEhmkvBioZxaUpmZmyPfjxwv60pIgbz5MDmgK7iS4+3mX6U
A5/TR5d8mUgjU+g4rk8Kb4Mu0UlXjIB0ttov0DiNewNwIRt18jA8+o+u3dpjq+sW
T8KOEUt+zwvo/7V3LvSye0rgTBIlDHCNAymg4VMk7BPZ7hm/ELNKjD+Jo2FR3qyH
B5T0Y3HsLuJvW5iB4YlcNHlsdu87kGJ55tukmi8mxdAQ4Q7e2RCOFvu396j3x+UC
B5iPNgiV5+I3lg02dZ77DnKxHZu8A/lJBdiB3QW0KtZB6awBdpUKD9jf1b0SHzUv
KBds0pjBqAlkd25HN7rOrFleaJ1/ctaJxQZBKT5ZPt0m9STJEadao0xAH0ahmbWn
OlFuhjuefXKnEgV4We0+UXgVCwOPjdAvBbI+e0ocS3MFEvzG6uBQE3xDk3SzynTn
jh8BCNAw1FtxNrQHusEwMFxIt4I7mKZ9YIqioymCzLq9gwQbooMDQaHWBfEbwrbw
qHyGO0aoSCqI3Haadr8faqU9GY/rOPNk3sgrDQoo//fb4hVC1CLQJ13hef4Y53CI
rU7m2Ys6xt0nUW7/vGT1M0NPAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV
HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR5tFnme7bl5AFzgAiIyBpY9umbbjANBgkq
hkiG9w0BAQsFAAOCAgEAVR9YqbyyqFDQDLHYGmkgJykIrGF1XIpu+ILlaS/V9lZL
ubhzEFnTIZd+50xx+7LSYK05qAvqFyFWhfFQDlnrzuBZ6brJFe+GnY+EgPbk6ZGQ
3BebYhtF8GaV0nxvwuo77x/Py9auJ/GpsMiu/X1+mvoiBOv/2X/qkSsisRcOj/KK
NFtY2PwByVS5uCbMiogziUwthDyC3+6WVwW6LLv3xLfHTjuCvjHIInNzktHCgKQ5
ORAzI4JMPJ+GslWYHb4phowim57iaztXOoJwTdwJx4nLCgdNbOhdjsnvzqvHu7Ur
TkXWStAmzOVyyghqpZXjFaH3pO3JLF+l+/+sKAIuvtd7u+Nxe5AW0wdeRlN8NwdC
jNPElpzVmbUq4JUagEiuTDkHzsxHpFKVK7q4+63SM1N95R1NbdWhscdCb+ZAJzVc
oyi3B43njTOQ5yOf+1CceWxG1bQVs5ZufpsMljq4Ui0/1lvh+wjChP4kqKOJ2qxq
4RgqsahDYVvTH9w7jXbyLeiNdd8XM2w9U/t7y0Ff/9yi0GE44Za4rF2LN9d11TPA
mRGunUHBcnWEvgJBQl9nJEiU0Zsnvgc/ubhPgXRR4Xq37Z0j4r7g1SgEEzwxA57d
emyPxgcYxn/eR44/KJ4EBs+lVDR3veyJm+kXQ99b21/+jh5Xos1AnX5iItreGCc=
-----END CERTIFICATE-----

#then using HOST = "www.google.com"
$ ./pyboard.py  simple.py 
attaching..attached!
connecting [##] connected!
certs accepted

#then using HOST = "www.johnedstone.net"
$ ./pyboard.py  simple_files/get_https/simple.py 
attaching..attached!
connecting [##] connected!
Traceback (most recent call last):
  File "<stdin>", line 37, in <module>
OSError: -9984
$ 

[Edward Johnstone]

@jcaron regarding the chain of certs. As noted in the example that I just posted, I am now using only the Root CA. I did try Let's Encrypt R3 alone and that did not work. Thanks again for thinking about this. I still think there is some mystery, as I am using Let's Encrypt Root CA after they replaced the expired one. This seems like it should be straightforward.

I am wondering how Firefox does this and looking in the browser db, it appears they have ISRG Root X1, the same as I am using - still a mystery

$ echo "select * from nssPublic" | sqlite3 cert9.db |egrep -i isrg
 Internet Security Research Group10U
                                    ISRG Root X1|||||||||||||021
                                                                0	UUS10U
 Internet Security Research Group10U
                                    ISRG Root X2|||||||||||||021
                                                                0	UUS10U

[jcaron]

@Edward-Johnstone The whole Let's Encrypt X3 root cert expiry has led to a complex situation which is not fully compatible with all clients.

Here is the list of certs your server sends:

Certificate chain
 0 s:CN = www.johnedstone.net
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3

It should stop at the second certificate, which is signed by ISRG Root X1, and if you have that root cert (as you do) then it should be all fine.

The issue is that quite a few devices, including Android phones < 7.1, don't have that root cert and don't get updates of root certs.

So they added the third certificate in the chain, which is another version of ISRG Root X1, signed by Root CA X3. That one is supposedly recognised by Android < 7.1 (despite the Root CA X3 cert being expired, because they trust the "anchor", not the cert), which improves compatibility somewhat.

But on the other hand, some other clients (including some versions of openSSL) don't stop at the second cert like they should (because they know the root which signed it), go to the third one, and then miserably fail because Root CA X3 is either expired or missing.

So you need a cert chain that only contains the first two certificates, not three. This is called the "alternate chain".

Two options to get the right cert chain (this must be done on your server, not on the client):

• Edit the relevant fullchain.pem and remove the last cert of the chain (or if you use separate cert + intermediate files, the last certificate in the chain.pem). But that needs to be done every time the cert is renewed
• Use --preferred-chain "ISRG Root X1" to re-issue a new certificate using certbot. Requires a recent version of certbot, but it will then save the setting and re-use it for renewals.

Note that you will lose compatibility with Android devices < 7.1. May or may not matter for you.

Of course this is all supposition, I haven't actually checked that this will really fix the issue on the Pycom devices, but there's a good chance it may.

[Edward Johnstone]

@jcaron said in https client using Let's Encrypt certs throws error:

--preferred-chain "ISRG Root X1"

Thank you for explaining this .... this makes sense. Let me explore this and I will post my results

[Edward Johnstone]

@Edward-Johnstone hmmm, so I fixed it on the server (using renew --preferred-chain "ISRG Root X1") and that didn't help.
Thank you for reminding me about openssl s_client. I had forgotten to think about that. Anyway, that didn't fix it, ... hmmm.

openssl s_client -connect www.johnedstone.net:443 -showcerts < /dev/null
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = www.johnedstone.net
verify return:1
---
Certificate chain
 0 s:CN = www.johnedstone.net
   i:C = US, O = Let's Encrypt, CN = R3
-----BEGIN CERTIFICATE-----
MIIEYjCCA0qgAwIBAgISA6qvfw4VmogisNpdOd/AaTrQMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMjAzMDIwMDE2MDBaFw0yMjA1MzEwMDE1NTlaMB4xHDAaBgNVBAMT
E3d3dy5qb2huZWRzdG9uZS5uZXQwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQ1
tClbocSYmpmnvI+p12J9Fm8hbfcNVs06YlMVIqXxYP9xLKyCzaedLUqv8EqyQdk/
EotPQH5KdUSXlBp4hcnyo4ICTzCCAkswDgYDVR0PAQH/BAQDAgeAMB0GA1UdJQQW
MBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBQd
AMYcsjSsSaonQs+eLX9zeSRjhzAfBgNVHSMEGDAWgBQULrMXt1hWy65QCUDmH6+d
ixTCxjBVBggrBgEFBQcBAQRJMEcwIQYIKwYBBQUHMAGGFWh0dHA6Ly9yMy5vLmxl
bmNyLm9yZzAiBggrBgEFBQcwAoYWaHR0cDovL3IzLmkubGVuY3Iub3JnLzAeBgNV
HREEFzAVghN3d3cuam9obmVkc3RvbmUubmV0MEwGA1UdIARFMEMwCAYGZ4EMAQIB
MDcGCysGAQQBgt8TAQEBMCgwJgYIKwYBBQUHAgEWGmh0dHA6Ly9jcHMubGV0c2Vu
Y3J5cHQub3JnMIIBBQYKKwYBBAHWeQIEAgSB9gSB8wDxAHYAKXm+8J45OSHwVnOf
Y6V35b5XfZxgCvj5TV0mXCVdx4QAAAF/SDLDygAABAMARzBFAiEAkY5SnweMC+RM
pNTWoa26sXTeo/PClIHoCb+hrH5KzpkCIDmeWW9rMyRjdupwkLOsNNVleGp+i0b0
qLRX4F8LcMRUAHcAb1N2rDHwMRnYmQCkURX/dxUcEdkCwQApBo2yCJo32RMAAAF/
SDLE0QAABAMASDBGAiEAlhihXbLej5uCFhexXZrKDhJiF9Qk5MPfLDvrUj7zepkC
IQD/9ryzlhBSuqcqomc1T4HBwwN8Yx5CFyJ5yQKPiLZP4TANBgkqhkiG9w0BAQsF
AAOCAQEAXbVZCSkfUhiIb3uZjF/5QlNxqM8mdKeAzA77hYzFQDzpngZDN9jG45VA
FAKymKITH6VO2lXx8U+qBgc7ri7y3ZeQX3hKRn4j3ps9L3RTU9KdtdsU/GPIM2zp
pLqNnBWEQsnYmJQF2NkVPjXJzStUkBW+EzyrYoOVyLn0u6iRvXTALM7XQ1vNVSqC
S1uxAWsSBoWZvjeETlBUPKfjTSmkVMvYc1X2er+cH7HWktn35hQ3KFBruYWy+mEG
x5xe/aXjH0VIht6tmDGDeM6PIxiXACeScIIHLmNVQM/J6duKLcswszD2eV7M9FNQ
kjTUu2C5wlGAEXXCZJzHSg8XiMpRfA==
-----END CERTIFICATE-----
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
-----BEGIN CERTIFICATE-----
MIIFFjCCAv6gAwIBAgIRAJErCErPDBinU/bWLiWnX1owDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMjAwOTA0MDAwMDAw
WhcNMjUwOTE1MTYwMDAwWjAyMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3Mg
RW5jcnlwdDELMAkGA1UEAxMCUjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC7AhUozPaglNMPEuyNVZLD+ILxmaZ6QoinXSaqtSu5xUyxr45r+XXIo9cP
R5QUVTVXjJ6oojkZ9YI8QqlObvU7wy7bjcCwXPNZOOftz2nwWgsbvsCUJCWH+jdx
sxPnHKzhm+/b5DtFUkWWqcFTzjTIUu61ru2P3mBw4qVUq7ZtDpelQDRrK9O8Zutm
NHz6a4uPVymZ+DAXXbpyb/uBxa3Shlg9F8fnCbvxK/eG3MHacV3URuPMrSXBiLxg
Z3Vms/EY96Jc5lP/Ooi2R6X/ExjqmAl3P51T+c8B5fWmcBcUr2Ok/5mzk53cU6cG
/kiFHaFpriV1uxPMUgP17VGhi9sVAgMBAAGjggEIMIIBBDAOBgNVHQ8BAf8EBAMC
AYYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMBIGA1UdEwEB/wQIMAYB
Af8CAQAwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYfr52LFMLGMB8GA1UdIwQYMBaA
FHm0WeZ7tuXkAXOACIjIGlj26ZtuMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcw
AoYWaHR0cDovL3gxLmkubGVuY3Iub3JnLzAnBgNVHR8EIDAeMBygGqAYhhZodHRw
Oi8veDEuYy5sZW5jci5vcmcvMCIGA1UdIAQbMBkwCAYGZ4EMAQIBMA0GCysGAQQB
gt8TAQEBMA0GCSqGSIb3DQEBCwUAA4ICAQCFyk5HPqP3hUSFvNVneLKYY611TR6W
PTNlclQtgaDqw+34IL9fzLdwALduO/ZelN7kIJ+m74uyA+eitRY8kc607TkC53wl
ikfmZW4/RvTZ8M6UK+5UzhK8jCdLuMGYL6KvzXGRSgi3yLgjewQtCPkIVz6D2QQz
CkcheAmCJ8MqyJu5zlzyZMjAvnnAT45tRAxekrsu94sQ4egdRCnbWSDtY7kh+BIm
lJNXoB1lBMEKIq4QDUOXoRgffuDghje1WrG9ML+Hbisq/yFOGwXD9RiX8F6sw6W4
avAuvDszue5L3sz85K+EC4Y/wFVDNvZo4TYXao6Z0f+lQKc0t8DQYzk1OXVu8rp2
yJMC6alLbBfODALZvYH7n7do1AZls4I9d1P4jnkDrQoxB3UqQ9hVl3LEKQ73xF1O
yK5GhDDX8oVfGKF5u+decIsH4YaTw7mP3GFxJSqv3+0lUFJoi5Lc5da149p90Ids
hCExroL1+7mryIkXPeFM5TgO9r0rvZaBFOvV2z0gp35Z0+L4WPlbuEjN/lxPFin+
HlUjr8gRsI3qfJOQFy/9rKIJR0Y/8Omwt/8oTWgy1mdeHmmjk7j1nYsvC9JSQ6Zv
MldlTTKB3zhThV1+XWYp6rjd5JW1zbVWEkLNxE7GJThEUG3szgBVGP7pSWTUTsqX
nLRbwHOoq7hHwg==
-----END CERTIFICATE-----
---
Server certificate
subject=CN = www.johnedstone.net

issuer=C = US, O = Let's Encrypt, CN = R3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2811 bytes and written 391 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
DONE