adafruit / nina-fw

Firmware for u-blox NINA W102 WiFi/BT module
85 stars 43 forks source link

Basic internet test no longer able to SSL to github #55

Closed dhalbert closed 11 months ago

dhalbert commented 1 year ago

After the certificate replacement in #51, the basic "Internet Test" used across all our CircuitPython wifi boards no longer connects to GitHub. See https://github.com/adafruit/circuitpython/issues/8299.

Looking at #51, I see that it replaces an existing certificate. When I enter the existing certificate, it does not show up as expired, but instead shows up as expiring in 2031.

Was the certificate revoked?

@brentru How did you decide to replace that particular certificate? I am wondering if a still-legit cert was replaced by accident.

brentru commented 1 year ago

@dhalbert - on https://github.com/adafruit/circuitpython/issues/8299, the internet test was performed using a MatrixPortal S3. That board doesn't run nina-fw. Is this issue being within nina-fw relevant?

Looking at https://github.com/adafruit/nina-fw/pull/51, I see that it replaces an existing certificate. When I enter the existing certificate, it does not show up as expired, but instead shows up as expiring in 2031. Was the certificate revoked?

I believe it was revoked - @martymcguire and @jwcooper would know for sure.

jwcooper commented 1 year ago

I believe Digicert updated their root and intermediate CA certificates in 2023, so we picked those up in this refresh: https://knowledge.digicert.com/generalinformation/digicert-root-and-intermediate-ca-certificate-updates-2023.html

dhalbert commented 1 year ago

@dhalbert - on adafruit/circuitpython#8299, the internet test was performed using a MatrixPortal S3. That board doesn't run nina-fw. Is this issue being within nina-fw relevant?

CircuitPython uses NINA-FW as a submodule to pick up the latest roots.pem for all our boards including native wifi like S3. So, yep, changes here affect CircuitPython certs.

tyeth commented 1 year ago

I wondered if there was a minor change or not, sadly my diff software couldn't pull off the moved block detection well enough, but this is the latest roots.pem from android, taken according to the instructions at https://github.com/arduino/nina-fw/blob/master/README.md#build-a-new-certificate-list-based-on-the-google-android-root-ca-list PR Added #56, happy to cancel it, but thought easiest to just pull fresh certs. Using the instructions to test the certs I verified api.github.com works on my branch, and not on master, io.adafruit.com works on both. image

tyeth commented 1 year ago

As a bit of a personal challenge I wanted to see if I could get WinMerge etc to do moved block detection well enough to understand the roots bundle changes. Yes and no.

I decided to play with Noteable (Jupyter notebooks, but works with chatgpt via plugin), and attempt to do moved block detection and looking up old certs, it worked well. I've also added the older certs to see what happened compared to the past.

This made me realise there was not a small change and we should probably accept the newer file rather than patching individual certs. I'd love to know what the unknown certs are (all removed by my update) so if anyone wants to suggest extensions to the notebook please do. https://app.noteable.io/f/dcd52f2d-0761-4287-b90c-ac419f130c16/root-certs.ipynb


Number of moved certificates: 23
{'USERTrust ECC Certification Authority': 'USERTrust ECC Certification Authority', 'GlobalSign Root CA - R3': 'GlobalSign Root CA - R3', 'Starfield Class 2 CA': 'Starfield Class 2 CA', 'GlobalSign ECC Root CA - R5': 'GlobalSign ECC Root CA - R5', 'USERTrust RSA Certification Authority': 'USERTrust RSA Certification Authority', 'Baltimore CyberTrust Root': 'Baltimore CyberTrust Root', 'COMODO Certification Authority': 'COMODO Certification Authority', 'ISRG Root X1': 'ISRG Root X1', 'DigiCert Assured ID Root CA': 'DigiCert Assured ID Root CA', 'Comodo AAA Services root': 'Comodo AAA Services root', 'Amazon Root CA 3': 'Amazon Root CA 3', 'DigiCert High Assurance EV Root CA': 'DigiCert High Assurance EV Root CA', 'Starfield Root Certificate Authority - G2': 'Starfield Root Certificate Authority - G2', 'COMODO ECC Certification Authority': 'COMODO ECC Certification Authority', 'DigiCert Assured ID Root G2': 'DigiCert Assured ID Root G2', 'GlobalSign Root CA - R6': 'GlobalSign Root CA - R6', 'DigiCert Trusted Root G4': 'DigiCert Trusted Root G4', 'GlobalSign Root CA': 'GlobalSign Root CA', 'DigiCert Assured ID Root G3': 'DigiCert Assured ID Root G3', 'DigiCert Global Root G2': 'DigiCert Global Root G2', 'COMODO RSA Certification Authority': 'COMODO RSA Certification Authority', 'DigiCert Global Root G3': 'DigiCert Global Root G3', 'Amazon Root CA 1': 'Amazon Root CA 1'}

Number of new certificates: 12
dict_keys(['GlobalSign ECC Root CA - R4', 'Starfield Services Root Certificate Authority - G2', 'GlobalSign Root R46', 'DigiCert Global Root CA', 'GTS Root R4', 'GTS Root R3', 'ISRG Root X2', 'GTS Root R2', 'Amazon Root CA 4', 'GlobalSign Root E46', 'GTS Root R1', 'Amazon Root CA 2'])

Number of removed certificates: 25
dict_keys(['Unknown1', 'Unknown2', 'Entrust Root Certification Authority', 'Unknown3', 'Unknown4', 'Unknown5', 'GlobalSign Root CA - R2', 'Go Daddy Root Certificate Authority - G2', 'Unknown6', 'Cybertrust Global Root', 'Unknown7', 'Entrust Root Certification Authority - EC1', 'Entrust Root Certification Authority - G2', 'Entrust.net Premium 2048 Secure Server CA', 'AffirmTrust Commercial', 'AffirmTrust Networking', 'AffirmTrust Premium', 'AffirmTrust Premium ECC', 'Unknown8', 'Go Daddy Class 2 CA', 'GlobalSign ECC Root CA - R4', 'GTS Root R1', 'GTS Root R2', 'GTS Root R3', 'GTS Root R4'])
crhuber commented 1 year ago

Having same issue connecting SSL to a website behind a cloudflare certificate

When running through this tutorial https://learn.adafruit.com/adafruit-pyportal/internet-connect#connect-to-wifi-17-4 I get a runtime error:

adafruit_requests.py line 515 in _get_socket. 
RuntimeError: sending request failed

Running nina 1.7.5 Circuit Python 8.26 on PyPortal

It worked fine before the URL in question switched to use cloudflare

dhalbert commented 1 year ago

@crhuber Could you try this NINA-FW firmware update? It has an updated certificate list, and works with the github URL https://api.github.com/repos/adafruit/circuitpython. That returns a lot of JSON so I had to trim the rest of the test program to avoid memory issues.

Unzip this and update the ESP32 AirLift firmware: NINA_W102-1.7.7.bin.zip

If it works I will submit a PR to nina-fw.

crhuber commented 1 year ago

I tested with 1.7.7 Nina FW and Circuit Python 8.2.6 it works with this url https://api.github.com/repos/adafruit/circuitpython.

but fails for a different url with a lets encrypt cert provided by cloudflare

dhalbert commented 1 year ago

Could you please give the failing URL, or at least a redacted version so we can try talking to the same server and looking at its certificate chain?

crhuber commented 1 year ago

@dhalbert try this one https://api.intra.io/api/v1/healthz

dhalbert commented 1 year ago

@crhuber I see that problem too, on a Metro M4 AirLift Lite using the NINA-FW firmware I posted above. But there is something strange going on with DNS for api.intra.io: The site works with curl:

$ curl https://api.intra.io/api/v1/healthz
{"status":"ok"}

But it doesn't work with openssl s_client [EDIT: fixed command] [EDIT2: command should only refer to the server, not the whole URL: see https://github.com/adafruit/nina-fw/issues/55#issuecomment-1728349451]

$ openssl s_client -showcerts -connect api.intra.io/api/v1/healthz:443 < /dev/null  #EDIT2: arg is WRONG
40877E77527F0000:error:10080002:BIO routines:BIO_lookup_ex:system lib:../crypto/bio/bio_addr.c:738:Name or service not known
connect:errno=22

I also tried that URL on a Metro ESP32-S2, and it works. That board is using CircuitPython with a roots.pem that is identical to the roots.pem used by the test 1.7.7 NINA-FW.

The cert chain as reported by Firefox is: *.intra.io server cert <- Let's Encrypt E1 <- ISRG Root X2 (using elliptic keys)

The ISRG Root X2 cert is in our roots.pem. But since openssl s_client cannot even look up the host, and it does work with CircuitPython ESP32-S2, I don't think it's a cert chain issue.

Do you have any idea of why openssl s_client can't look up the host? I'm hypothesizing the same issue is affecting NINA-FW.

tyeth commented 1 year ago

@dhalbert same with my domains, maybe easier to diagnose/test. good-enough.cloud is cloudflare letsencrypt E1, but good-enough.technology is certbot letsencrypt R3. Both should resolve okay.

-Edit-

Result of running openssl check against E1 cloud tld: ``` tyeth@lenovo447:/mnt/c/Users/tyeth$ openssl s_client -showcerts -connect good-enough.cloud:443 < /dev/null CONNECTED(00000003) depth=3 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X2 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = E1 verify return:1 depth=0 CN = good-enough.cloud verify return:1 --- Certificate chain 0 s:CN = good-enough.cloud i:C = US, O = Let's Encrypt, CN = E1 a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA384 v:NotBefore: Aug 9 05:43:27 2023 GMT; NotAfter: Nov 7 05:43:26 2023 GMT -----BEGIN CERTIFICATE----- MIIDmzCCAyCgAwIBAgISBMQxoW4bhlrjaYEAf2Ul/Dx7MAoGCCqGSM49BAMDMDIx CzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQDEwJF MTAeFw0yMzA4MDkwNTQzMjdaFw0yMzExMDcwNTQzMjZaMBwxGjAYBgNVBAMTEWdv b2QtZW5vdWdoLmNsb3VkMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEXrmWRuXo toJOsDh7eOPpXSQjG+FrhBgx141IRYTcb3xHZPrICwHFUxmhh/mExCGfzF+7dJ3o GE5rnVU6VMDkDKOCAiowggImMA4GA1UdDwEB/wQEAwIHgDAdBgNVHSUEFjAUBggr BgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQU3ZVN1ugU q/oRk2/om8uh+vHDqRIwHwYDVR0jBBgwFoAUWvPtK/w2wjd5uVIw6lRvz1XLLqww VQYIKwYBBQUHAQEESTBHMCEGCCsGAQUFBzABhhVodHRwOi8vZTEuby5sZW5jci5v cmcwIgYIKwYBBQUHMAKGFmh0dHA6Ly9lMS5pLmxlbmNyLm9yZy8wMQYDVR0RBCow KIITKi5nb29kLWVub3VnaC5jbG91ZIIRZ29vZC1lbm91Z2guY2xvdWQwEwYDVR0g BAwwCjAIBgZngQwBAgEwggEGBgorBgEEAdZ5AgQCBIH3BIH0APIAdwC3Pvsk35xN unXyOcW6WPRsXfxCz3qfNcSeHQmBJe20mQAAAYnZCTedAAAEAwBIMEYCIQDKoP69 1kGsYyXydVcW5VpGbRgmz6n/QQaiv2I920PcgwIhAI9i490BybS23jJ3Id8Xdq0U 4skgSmXbpvrrRCsNqzL+AHcA6D7Q2j71BjUy51covIlryQPTy9ERa+zraeF3fW0G vW4AAAGJ2Qk3cwAABAMASDBGAiEA+ulNUcIK6eEfR8TrZuMPhZ8o43WE+zvfM/ot GOhmHGMCIQCIljX6oLOieERy+xwKn5DhXpnP4FO4ed5JJIA2urMuazAKBggqhkjO PQQDAwNpADBmAjEAnIWHfhhRmW0rTyR/NK4FjDkd9o40s7RxO0UM+LHieaeQi5Lo 7VxBunX/QklrWmRTAjEAtiRoekVvg+wPIxkfSA09CchGYdIec7hLGS3QWI/uMVco yb3Gg8dDjuaNKDJ14Dg6 -----END CERTIFICATE----- 1 s:C = US, O = Let's Encrypt, CN = E1 i:C = US, O = Internet Security Research Group, CN = ISRG Root X2 a:PKEY: id-ecPublicKey, 384 (bit); sigalg: ecdsa-with-SHA384 v:NotBefore: Sep 4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT -----BEGIN CERTIFICATE----- MIICxjCCAk2gAwIBAgIRALO93/inhFu86QOgQTWzSkUwCgYIKoZIzj0EAwMwTzEL MAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2VhcmNo IEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDIwHhcNMjAwOTA0MDAwMDAwWhcN MjUwOTE1MTYwMDAwWjAyMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3MgRW5j cnlwdDELMAkGA1UEAxMCRTEwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAAQkXC2iKv0c S6Zdl3MnMayyoGli72XoprDwrEuf/xwLcA/TmC9N/A8AmzfwdAVXMpcuBe8qQyWj +240JxP2T35p0wKZXuskR5LBJJvmsSGPwSSB/GjMH2m6WPUZIvd0xhajggEIMIIB BDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMB MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFFrz7Sv8NsI3eblSMOpUb89V yy6sMB8GA1UdIwQYMBaAFHxClq7eS0g7+pL4nozPbYupcjeVMDIGCCsGAQUFBwEB BCYwJDAiBggrBgEFBQcwAoYWaHR0cDovL3gyLmkubGVuY3Iub3JnLzAnBgNVHR8E IDAeMBygGqAYhhZodHRwOi8veDIuYy5sZW5jci5vcmcvMCIGA1UdIAQbMBkwCAYG Z4EMAQIBMA0GCysGAQQBgt8TAQEBMAoGCCqGSM49BAMDA2cAMGQCMHt01VITjWH+ Dbo/AwCd89eYhNlXLr3pD5xcSAQh8suzYHKOl9YST8pE9kLJ03uGqQIwWrGxtO3q YJkgsTgDyj2gJrjubi1K9sZmHzOa25JK1fUpE8ZwYii6I4zPPS/Lgul/ -----END CERTIFICATE----- 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X2 i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 a:PKEY: id-ecPublicKey, 384 (bit); sigalg: RSA-SHA256 v:NotBefore: Sep 4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT -----BEGIN CERTIFICATE----- MIIEYDCCAkigAwIBAgIQB55JKIY3b9QISMI/xjHkYzANBgkqhkiG9w0BAQsFADBP MQswCQYDVQQGEwJVUzEpMCcGA1UEChMgSW50ZXJuZXQgU2VjdXJpdHkgUmVzZWFy Y2ggR3JvdXAxFTATBgNVBAMTDElTUkcgUm9vdCBYMTAeFw0yMDA5MDQwMDAwMDBa Fw0yNTA5MTUxNjAwMDBaME8xCzAJBgNVBAYTAlVTMSkwJwYDVQQKEyBJbnRlcm5l dCBTZWN1cml0eSBSZXNlYXJjaCBHcm91cDEVMBMGA1UEAxMMSVNSRyBSb290IFgy MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEzZvVn4CDCuwJSvMWSj5cz3es3mcFDR0H ttwW+1qLFNvicWDEukWVEYmO6gbf9yoWHKS5xcUy4APgHoIYOIvXRdgKam7mAHf7 AlF9ItgKbppbd9/w+kHsOdx1ymgHDB/qo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjAP BgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBR8Qpau3ktIO/qS+J6Mz22LqXI3lTAf BgNVHSMEGDAWgBR5tFnme7bl5AFzgAiIyBpY9umbbjAyBggrBgEFBQcBAQQmMCQw IgYIKwYBBQUHMAKGFmh0dHA6Ly94MS5pLmxlbmNyLm9yZy8wJwYDVR0fBCAwHjAc oBqgGIYWaHR0cDovL3gxLmMubGVuY3Iub3JnLzAiBgNVHSAEGzAZMAgGBmeBDAEC ATANBgsrBgEEAYLfEwEBATANBgkqhkiG9w0BAQsFAAOCAgEAG38lK5B6CHYAdxjh wy6KNkxBfr8XS+Mw11sMfpyWmG97sGjAJETM4vL80erb0p8B+RdNDJ1V/aWtbdIv P0tywC6uc8clFlfCPhWt4DHRCoSEbGJ4QjEiRhrtekC/lxaBRHfKbHtdIVwH8hGR Ib/hL8Lvbv0FIOS093nzLbs3KvDGsaysUfUfs1oeZs5YBxg4f3GpPIO617yCnpp2 D56wKf3L84kHSBv+q5MuFCENX6+Ot1SrXQ7UW0xx0JLqPaM2m3wf4DtVudhTU8yD ZrtK3IEGABiL9LPXSLETQbnEtp7PLHeOQiALgH6fxatI27xvBI1sRikCDXCKHfES c7ZGJEKeKhcY46zHmMJyzG0tdm3dLCsmlqXPIQgb5dovy++fc5Ou+DZfR4+XKM6r 4pgmmIv97igyIintTJUJxCD6B+GGLET2gUfA5GIy7R3YPEiIlsNekbave1mk7uOG nMeIWMooKmZVm4WAuR3YQCvJHBM8qevemcIWQPb1pK4qJWxSuscETLQyu/w4XKAM YXtX7HdOUM+vBqIPN4zhDtLTLxq9nHE+zOH40aijvQT2GcD5hq/1DhqqlWvvykdx S2McTZbbVSMKnQ+BdaDmQPVkRgNuzvpqfQbspDQGdNpT2Lm4xiN9qfgqLaSCpi4t EcrmzTFYeYXmchynn9NM0GbQp7s= -----END CERTIFICATE----- 3 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1 i:O = Digital Signature Trust Co., CN = DST Root CA X3 a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256 v:NotBefore: Jan 20 19:14:03 2021 GMT; NotAfter: Sep 30 18:14:03 2024 GMT -----BEGIN CERTIFICATE----- MIIFYDCCBEigAwIBAgIQQAF3ITfU6UK47naqPGQKtzANBgkqhkiG9w0BAQsFADA/ MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT DkRTVCBSb290IENBIFgzMB4XDTIxMDEyMDE5MTQwM1oXDTI0MDkzMDE4MTQwM1ow TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwggIiMA0GCSqGSIb3DQEB AQUAA4ICDwAwggIKAoICAQCt6CRz9BQ385ueK1coHIe+3LffOJCMbjzmV6B493XC ov71am72AE8o295ohmxEk7axY/0UEmu/H9LqMZshftEzPLpI9d1537O4/xLxIZpL wYqGcWlKZmZsj348cL+tKSIG8+TA5oCu4kuPt5l+lAOf00eXfJlII1PoOK5PCm+D LtFJV4yAdLbaL9A4jXsDcCEbdfIwPPqPrt3aY6vrFk/CjhFLfs8L6P+1dy70sntK 4EwSJQxwjQMpoOFTJOwT2e4ZvxCzSow/iaNhUd6shweU9GNx7C7ib1uYgeGJXDR5 bHbvO5BieebbpJovJsXQEOEO3tkQjhb7t/eo98flAgeYjzYIlefiN5YNNnWe+w5y sR2bvAP5SQXYgd0FtCrWQemsAXaVCg/Y39W9Eh81LygXbNKYwagJZHduRze6zqxZ Xmidf3LWicUGQSk+WT7dJvUkyRGnWqNMQB9GoZm1pzpRboY7nn1ypxIFeFntPlF4 FQsDj43QLwWyPntKHEtzBRL8xurgUBN8Q5N0s8p0544fAQjQMNRbcTa0B7rBMDBc SLeCO5imfWCKoqMpgsy6vYMEG6KDA0Gh1gXxG8K28Kh8hjtGqEgqiNx2mna/H2ql PRmP6zjzZN7IKw0KKP/32+IVQtQi0Cdd4Xn+GOdwiK1O5tmLOsbdJ1Fu/7xk9TND TwIDAQABo4IBRjCCAUIwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYw SwYIKwYBBQUHAQEEPzA9MDsGCCsGAQUFBzAChi9odHRwOi8vYXBwcy5pZGVudHJ1 c3QuY29tL3Jvb3RzL2RzdHJvb3RjYXgzLnA3YzAfBgNVHSMEGDAWgBTEp7Gkeyxx +tvhS5B1/8QVYIWJEDBUBgNVHSAETTBLMAgGBmeBDAECATA/BgsrBgEEAYLfEwEB ATAwMC4GCCsGAQUFBwIBFiJodHRwOi8vY3BzLnJvb3QteDEubGV0c2VuY3J5cHQu b3JnMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaWRlbnRydXN0LmNvbS9E U1RST09UQ0FYM0NSTC5jcmwwHQYDVR0OBBYEFHm0WeZ7tuXkAXOACIjIGlj26Ztu MA0GCSqGSIb3DQEBCwUAA4IBAQAKcwBslm7/DlLQrt2M51oGrS+o44+/yQoDFVDC 5WxCu2+b9LRPwkSICHXM6webFGJueN7sJ7o5XPWioW5WlHAQU7G75K/QosMrAdSW 9MUgNTP52GE24HGNtLi1qoJFlcDyqSMo59ahy2cI2qBDLKobkx/J3vWraV0T9VuG WCLKTVXkcGdtwlfFRjlBz4pYg1htmf5X6DYO8A4jqv2Il9DjXA6USbW1FzXSLr9O he8Y4IWS6wY7bCkjCWDcRQJMEhg76fsO3txE+FiYruq9RUWhiF1myv4Q6W+CyBFC Dfvp7OOGAN6dEOM4+qR9sdjoSYKEBpsr6GtPAQw4dy753ec5 -----END CERTIFICATE----- --- Server certificate subject=CN = good-enough.cloud issuer=C = US, O = Let's Encrypt, CN = E1 --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: ECDSA Server Temp Key: X25519, 253 bits --- SSL handshake has read 4468 bytes and written 399 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 ```

Certbot version:

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 = good-enough.technology
verify return:1
---

cloudflare version:

CONNECTED(00000003)
depth=3 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X2
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = E1
verify return:1
depth=0 CN = good-enough.cloud
verify return:1
---
crhuber commented 1 year ago

@dhalbert I think the command you used for openssl was incorrect. I dont think you need the url path in the command.

Also on cloudflare I tried disabling TLS 1.3 and changing Minimum TLS to 1.2 (from 1.0) but no difference

dhalbert commented 1 year ago

@crhuber you are right; I was cutting and pasting the commands and missed that. Will investigate further.

dhalbert commented 1 year ago

If I set esp._debug = True in the standard Internet test (which I slightly modified to fetch only the intra.io URL), it appears that the NINA-FW code is crashing:

Fetching and parsing json from https://api.intra.io/api/v1/healthz
*** Get host by name
*** Get socket
Allocated socket #0
*** Socket connect mode 2
*** Open socket to api.intra.io 443 2
*** Closing socket #0
Traceback (most recent call last):
  File "adafruit_requests.py", line 515, in _get_socket
  File "adafruit_requests.py", line 748, in connect
  File "adafruit_esp32spi/adafruit_esp32spi_socket.py", line 77, in connect
  File "adafruit_esp32spi/adafruit_esp32spi.py", line 819, in socket_connect
  File "adafruit_esp32spi/adafruit_esp32spi.py", line 715, in socket_open
  File "adafruit_esp32spi/adafruit_esp32spi.py", line 341, in _send_command_get_response
  File "adafruit_esp32spi/adafruit_esp32spi.py", line 297, in _wait_response_cmd
  File "adafruit_esp32spi/adafruit_esp32spi.py", line 206, in _wait_for_ready
TimeoutError: ESP32 not responding
dhalbert commented 1 year ago

I am going to split off the https://api.intra.io/api/v1/healthz problem into a new issue, because the original github issue is solvable. But we do need to debug the intra.io issue.