Hello,
When my site finished deploying, I receive the following error message in the browser: NET::ERR_CERT_COMMON_NAME_INVALID.
I am not sure why and there does not appear to be any build errors. My site is https://agithubfinder.netlify.app/.
Please help, thanks!
hi there, which custom domain is this regarding?
i see “page not found” when I check that link - here is a guide to resolving that.
COMMON NAME INVALID is an error we see when someone is trying to access a custom domain such as “www.mycooldomain.com”. Have you added a custom domain to your site? if so, which ?
Perry, when I check for a custom domain, I still get the same message for https://agithubfinder.netlify.app/.
I am also getting the same error for https://johnathanguzman.netlify.app/. I don’t know why. It was not like this a few days ago. Could it be because I set a custom domain for my other site? I am also getting the error here : https://a-giphy-app.netlify.app/.
Attached is a screenshot of the error.
Hi, @Jguz17, for agithubfinder, I think you need a publish directory setting of “public”. I see the index.html file here (at /public/ instead of at / alone):
https://agithubfinder.netlify.app/public/
For the SSL issue, that I cannot explain. It would help to know the following details about the HTTP response with the bad SSL certificate.
The fastest way to do this is to send us the x-nf-request-id header which we send with every HTTP response.
There more information about this header here:
If that header isn’t available for any reason, please send the information it replaces (or as many of these details as possible). Those details are:
I am on https://johnathanguzman.netlify.app/.
There is no x-nf-request-id provided for this.
My Ip address is 2601:241:8701:a400:45a9:762e:627d:96a1.
I don’t know where the IP address for the cdn node is.
I made this request on Oct. 2 2020.
The time of request is 10:31am.
And the timezone is CST.
I think this is an issue with ALL of my netlify apps. This was not an issue last week. Do you know what could’ve happened ?
I think it is something with my wifi?
I get the following from the error page
’ Your connection is not private
Attackers might be trying to steal your information from johnathanguzman.netlify.app (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_COMMON_NAME_INVALID
Subject: low-xdns.xfinity.com
Issuer: COMODO RSA Organization Validation Secure Server CA
Expires on: Jul 8, 2022
Current date: Oct 2, 2020
PEM encoded chain:-----BEGIN CERTIFICATE-----
MIIHLzCCBhegAwIBAgIQNZp71/MXN6Q4ex3+YDjAkzANBgkqhkiG9w0BAQsFADCB
ljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPDA6BgNV
BAMTM0NPTU9ETyBSU0EgT3JnYW5pemF0aW9uIFZhbGlkYXRpb24gU2VjdXJlIFNl
cnZlciBDQTAeFw0yMDA3MDgwMDAwMDBaFw0yMjA3MDgyMzU5NTlaMIGxMQswCQYD
VQQGEwJVUzEOMAwGA1UEERMFMTkxMDMxFTATBgNVBAgTDFBlbm5zeWx2YW5pYTEV
MBMGA1UEBxMMUGhpbGFkZWxwaGlhMRkwFwYDVQQJExAxIENvbWNhc3QgQ2VudGVy
MRwwGgYDVQQKExNDb21jYXN0IENvcnBvcmF0aW9uMQwwCgYDVQQLEwNOU08xHTAb
BgNVBAMTFGxvdy14ZG5zLnhmaW5pdHkuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEA7qkCbxcqC0OGHl5XVkqm6hPlCYxKU0Ft2XmgbQVMykZpool1
I6Q67tZORQ0HTIh9UENuy7hrMOZqs/xUvB1MZtVzYSbq49GsLKeYANhZtJWLfyED
Pqg/tlTUzgOF6m0w9xcDc1Yln7npwYnTeK2iI/gZUwA6UgfZrUt9xo0XbIIDZDWS
Cg/YS4X9sKjz0WMzUpTtPHxpOSkdchjruC7XsC5ZtgQuCxyjc3cunXBfdWM7+9RN
7WpCyZv7PCTC9I6La/Srh1cHBLk8gkVJ/Sycgao88lyFED7kglBjxgxwm6WajBXz
UGV2YxE4KJLQMZdeW2c5Ld5sAQBSnxk8+cDznwIDAQABo4IDWjCCA1YwHwYDVR0j
BBgwFoAUmvMr2s+tT7YvuypISCoStxtCwSQwHQYDVR0OBBYEFKHNUc7K4DP7NJw0
LXVE+8hPOyEaMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQW
MBQGCCsGAQUFBwMBBggrBgEFBQcDAjBKBgNVHSAEQzBBMDUGDCsGAQQBsjEBAgED
BDAlMCMGCCsGAQUFBwIBFhdodHRwczovL3NlY3RpZ28uY29tL0NQUzAIBgZngQwB
AgIwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09N
T0RPUlNBT3JnYW5pemF0aW9uVmFsaWRhdGlvblNlY3VyZVNlcnZlckNBLmNybDCB
iwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LmNvbW9kb2Nh
LmNvbS9DT01PRE9SU0FPcmdhbml6YXRpb25WYWxpZGF0aW9uU2VjdXJlU2VydmVy
Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wggF+
BgorBgEEAdZ5AgQCBIIBbgSCAWoBaAB2AEalVet1+pEgMLWiiWn0830RLEF0vv1J
uIWr8vxw/m1HAAABczAObrIAAAQDAEcwRQIgDH4+Lrgkpv5Lwz13xPw20zfs5Vv6
3Gbs67Yy0FqmBkACIQDH+2ZjWXuthM/r+9AKETkmd3Rr+2stqIAkgJcu5HF0agB2
AN+lXqtogk8fbK3uuF9OPlrqzaISpGpejjsSwCBEXCpzAAABczAObtsAAAQDAEcw
RQIgTRXbPzUCj/JyZYYu148CPhktlQ9sdpyY5HjiAv7OmlsCIQDLsbIA4gdt9xys
cKj4MIgMi2jBo+PPswF13t5IopScjAB2AG9Tdqwx8DEZ2JkApFEV/3cVHBHZAsEA
KQaNsgiaN9kTAAABczAObqsAAAQDAEcwRQIgbSruXW3+OB7Touh48JGTi+WeQy9O
FnC+4ZQIgQEawFQCIQDhFTZ6ITMo0Rqcw2YBcZY2dUqq5DCHgbgD1N2W02XK0TAf
BgNVHREEGDAWghRsb3cteGRucy54ZmluaXR5LmNvbTANBgkqhkiG9w0BAQsFAAOC
AQEADiOA4oasiG4WL6FJaISKhEd5OuB8uco9PW4ONpxK4KgkIiwvyfA7WhdQET69
Npq9eFez8zBEdFlbvizh4Al4tj6Q5wl1ECFEcIXtA8smTFAya2GF2srLjyvKBEey
JUdZyDGYGyp2yiHsrIuSbBiiuZBPFfVaVLDbP75j/VaNGPKmmXMaQlrq+AymMmG+
eyJ87HFU/Wy2Wtb3EO3paZxTBAcrobif9ntvMvfXGHesLRJaGiaVCmo0bljG7CKf
O/qwrSHFmYG+5AZz5z9aDwIiQ+VOuitITy1SeiUHPw+488ZLd+Q+kNzXmOW9nbhZ
A2TgwJkcBUiy+zbrKbjKE/C03A==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIGDjCCA/agAwIBAgIQNoJef7WkgZN+9tFza7k8pjANBgkqhkiG9w0BAQwFADCB
hTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNV
BAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTQwMjEy
MDAwMDAwWhcNMjkwMjExMjM1OTU5WjCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgT
EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxPDA6BgNVBAMTM0NPTU9ETyBSU0EgT3JnYW5pemF0
aW9uIFZhbGlkYXRpb24gU2VjdXJlIFNlcnZlciBDQTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBALkU2YXyQURX/zBEHtw8RKMXuG4B+KNfwqkhHc5Z9Ozz
iKkJMjyxi2OkPic284/5OGYuB5dBj0um3cNfnnM858ogDU98MgXPwS5IZUqF0B9W
MW2O5cYy1Bu8n32W/JjXT/j0WFb440W+kRiC5Iq+r81SN1GHTx6Xweg6rvn/RuRl
Pz/DR4MvzLhCXi1+91porl1LwKY1IfWGo8hJi5hjYA3JIUjCkjBlRrKGNQRCJX6t
p05LEkAAeohoXG+fo6R4ESGuPQsOvkUUI8/rddf2oPG8RWxevKEy7PNYeEIoCzoB
dvDFoJ7BaXDej0umed/ydrbjDxN8GDuxUWxqIDnOnmkCAwEAAaOCAWUwggFhMB8G
A1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSa8yvaz61P
ti+7KkhIKhK3G0LBJDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIB
ADAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwGwYDVR0gBBQwEjAGBgRV
HSAAMAgGBmeBDAECAjBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9k
b2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggr
BgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29t
L0NPTU9ET1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz
cC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAGmKNmiaHjtlC+B8z6ar
cTuvYaQ/5GQBSRDTHY/i1e1n055bl71CHgf50Ltt9zKVWiIpYvgMnFlWJzagIhIR
+kf0UclZeylKpUg1fMWXZuAnJTsVejJ1SpH7pmue4lP6DYwT+yO4CxIsru3bHUeQ
1dCTaXaROBU01xjqfrxrWN4qOZADRARKVtho5fV8aX6efVRL0NiGq2dmE1deiSoX
rS2uvUAOZu2K/1S0wQHLqeBHuhFhj62uI0gqxiV5iRxBBJXAEepXK9a0l/qx6RVi
7Epxd/3zoZza9msAKcUy5/pO6rMqpxiXHFinQjZf7BTP+HsO993MiBWamlzI8SDH
0YZyoRebrrr+bKgy0QB2SXP3PyeHPLbJLfqqkJDJCgmfyWkfBxmpv966+AuIgkQW
EH8HwIAiX3+8MN66zQd5ZFbY//NPnDC7bh5RS+bNvRfExb/IP46xH4pGtwZDb2It
z1GdRcqK6ROLwMeRvlu2+jdKif7wndoTJiIsBpA+ixOYoBnW3dpKSH89D4mdJHJL
DntE/9Q2toN2I1iLFGy4XfdhbTl27d0SPWuHiJeRvsBGAh52HN22r1xP9QDWnE2p
4J6ijvyxFnlcIdNFgZoMOWxtKNcl0rcRkND23m9e9Pqki2Z3ci+bkEAsUhJg+f+1
cC6JmnkJiYEt7Fx4b4GH8fxV
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIF2DCCA8CgAwIBAgIQTKr5yttjb+Af907YWwOGnTANBgkqhkiG9w0BAQwFADCB
hTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNV
BAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTAwMTE5
MDAwMDAwWhcNMzgwMTE4MjM1OTU5WjCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgT
EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCR
6FSS0gpWsawNJN3Fz0RndJkrN6N9I3AAcbxT38T6KhKPS38QVr2fcHK3YX/JSw8X
pz3jsARh7v8Rl8f0hj4K+j5c+ZPmNHrZFGvnnLOFoIJ6dq9xkNfs/Q36nGz637CC
9BR++b7Epi9Pf5l/tfxnQ3K9DADWietrLNPtj5gcFKt+5eNu/Nio5JIk2kNrYrhV
/erBvGy2i/MOjZrkm2xpmfh4SDBF1a3hDTxFYPwyllEnvGfDyi62a+pGx8cgoLEf
Zd5ICLqkTqnyg0Y3hOvozIFIQ2dOciqbXL1MGyiKXCJ7tKuY2e7gUYPDCUZObT6Z
+pUX2nwzV0E8jVHtC7ZcryxjGt9XyD+86V3Em69FmeKjWiS0uqlWPc9vqv9JWL7w
qP/0uK3pN/u6uPQLOvnoQ0IeidiEyxPx2bvhiWC4jChWrBQdnArncevPDt09qZah
SL0896+1DSJMwBGB7FY79tOi4lu3sgQiUpWAk2nojkxl8ZEDLXB0AuqLZxUpaVIC
u9ffUGpVRr+goyhhf3DQw6KqLCGqR84onAZFdr+CGCe01a60y1Dma/RMhnEw6abf
Fobg2P9A3fvQQoh/ozM6LlweQRGBY84YcWsr7KaKtzFcOmpH4MN5WdYgGq/yapiq
crxXStJLnbsQ/LBMQeXtHT1eKJ2czL+zUdqnR+WEUwIDAQABo0IwQDAdBgNVHQ4E
FgQUu69+Aj36pvE8hI6t7jiY7NkyMtQwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB
/wQFMAMBAf8wDQYJKoZIhvcNAQEMBQADggIBAArx1UaEt65Ru2yyTUEUAJNMnMvl
wFTPoCWOAvn9sKIN9SCYPBMtrFaisNZ+EZLpLrqeLppysb0ZRGxhNaKatBYSaVqM
4dc+pBroLwP0rmEdEBsqpIt6xf4FpuHA1sj+nq6PK7o9mfjYcwlYRm6mnPTXJ9OV
2jeDchzTc+CiR5kDOF3VSXkAKRzH7JsgHAckaVd4sjn8OoSgtZx8jb8uk2Intzna
FxiuvTwJaP+EmzzV1gsD41eeFPfR60/IvYcjt7ZJQ3mFXLrrkguhxuhoqEwWsRqZ
CuhTLJK7oQkYdQxlqHvLI7cawiiFwxv/0Cti76R7CZGYZ4wUAc1oBmpjIXUDgIiK
boHGhfKppC3n9KUkEEeDys30jXlYsQab5xoq2Z0B15R97QNKyvDb6KkBPvVWmcke
jkk9u+UJueBPSZI9FoJAzMxZxuY67RIuaTxslbH9qh17f4a+Hg4yRvv7E491f0yL
S0Zj/gA0QHDBw7mh3aZw4gSzQbzpgJHqZJx64SIDqZxubw5lT2yHh17zbqD5daWb
QOhTsiedSrnAdyGN/4fy3ryM7xfft0kL0fJuMAsaDk527RH89elWsn2/x20Kk4yl
0MC2Hb46TpSi125sC8KKfPog88Tk5c0NqMuRkrF8hey1FGlmDoLnzc7ILaZRfyHB
NVOFBkpdn627G190
-----END CERTIFICATE-----’
Hi, @Jguz17. My best guess is that there is some sort of DNS issue occurring. This looks like a SSL certificate belonging to your ISP (because of “xfinity.com” string here):
Subject: low-xdns.xfinity.com
Can you please confirm the IP address you are seeing locally for that site’s hostname? Most systems have an nslookup command for this:
$ nslookup johnathanguzman.netlify.app
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: johnathanguzman.netlify.app
Address: 104.248.78.23
Name: johnathanguzman.netlify.app
Address: 104.248.78.24
If you are able to check the IP address being returned for johnathanguzman.netlify.app, I’ fairly sure we will be able to confirm that this is not a Netlify controlled IP address.
Note, there are dozens of different IP address for this one domain name. Which IP address is returned will depend on the geographic location of the request making the DNS lookup. You can see this here:
https://dnschecker.org/#A/johnathanguzman.netlify.app
Looking at some examples, for Lille, France one IP address is: 134.209.226.211. This is an IP address which routes to a system in or near Frankfurt, Germany.
For São Paulo, Brazil one IP address is: 18.230.52.212. This is an IP address in or near São Paulo.
When I look up the ownership of these IP addresses, I can confirm they are part of the networks of the cloud service providers (DigitalOcean, AWS, Packet, etc) our CDN nodes are built using. I also see that they are IP addresses we (meaning Netlify) currently control.
If you perform similar DNS lookups locally, I’m guessing that the IP address returning the ‘xfinity’ SSL certificate will be an IP address owned by your ISP.
So, how do you fix this? First, you might contact your ISP’s technical support ask them about why this DNS lookup isn’t being returned correctly by their DNS service.
Alternatively, you might just switch to a different DNS resolver and skip the your ISP’s DNS entirely. (There are even encrypted DNS services to prevent your ISP from observing or modifying your DNS lookups.) You might change local computer to use DNS from OpenNIC or Google. Please note those two projects are likely polar opposites in respect to how your data will be used when using them.
One last thing about changing the DNS service. If you do decide to do this, most home networks control this automatically for all devices in the household in the wireless router setup. If you pick a different set of IP addresses to use for DNS resolvers (like 8.8.8.8 and 8.8.4.4), you might change these defaults in your wireless router’s “DHCP” settings so all devices on your network will use those settings. (This can sometimes much faster than changing the setting on several devices manually. You may still need to reconnect the devices by turning wifi off/on or rebooting the devices.)
To sum up, either contact the ISP technical support about the DNS issue (if that is what it is). Again, if DNS is the issue, you might also just switch your DNS service.
If there are questions about any of this, please let us know.
Hi, @gpickett00. I don’t think we 100% confirmed the root cause here and there was no resolution reported.
From the SSL certificate returned and the behavior described, I’m personally 99.99% sure this was a case of DNS hijacking by an ISP:
To summarize, I believe @Jguz17’s ISP was sending him the wrong IP address for our domain name when the DNS query was sent to their DNS server. The SSL certificate was the SSL for this ISP’s webserver and because they redirected the DNS to their IP address and not the one for the real site at Netlify. The SSL was wrong because he was sent to the wrong server by his ISP. As the wiki page above mentions, this is unfortunately an all too common practice for even major ISPs.
This could be what is happening in your case but we need more information to be sure. We need the DNS lookup for the domain name and we also need to know what DNS server is answering. On many systems, you can get this information with nslookup. For example:
$ nslookup example.netlify.app
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: example.netlify.app
Address: 104.248.78.23
Name: example.netlify.app
Address: 167.172.221.254
In the output above I can see for my query about the IP address for “example.netlify.app” the answer was two the IP addresses below:
The DNS server that returned the answer had the IP address of 8.8.8.8.
If you are experiencing DNS hijacking, I would recommend changing the IP address for your network’s DNS resolver:
You can also try contacting the technical support team for your ISP and ask them to correct the behavior of the DNS server which failing to return the authoritative DNS records for the zone.
Again, I’m not sure if this is even what is happening to you (but I do believe this was the issue for @Jguz17). Would you please confirm exactly the error message you are seeing and, if you think it is pertinent, would you also send us the nslookup output for the site with this issue?
It’s been a while since this thread has had any action, but I wanted to see if there was any solution to this issue. I am using Netlify for our company’s web applications and have heard of 3 instances of a similar issue. We have 3 apps, 2 are a subdomain of one domain name and the other one has it’s own domain name. All 3 are being affected. It seems to only be happening with Xfinity/Comcast users and in particular, since we are a Portland Oregon based company, the 3 occurrences have been in the northern half of the Portland area and just over the Washington state line. This issue is not happening south of Portland. The error that shows up for them is this: ERR_SSL_PROTOCOL_ERROR - I can include nslookup screen shots too if necessary. Thanks!
Hi Luke! Thanks for your quick response.
I’ve gathered the information (most of it anyway) that you requested…
The other urls that this happens to are …
When I checked with the user today, these 2 worked but were not working a few days ago.
Also, we are using Cloudflare as a DNS manager, if that information helps in any way.
Thanks again for your help in solving this issue.
Hi, @cmonster52. I’m showing that as a successful page load and no SSL issues for that request id. Also, the x-nf-request-id doesn’t get sent if the browser closes the connection because of SSL errors which is why the other information was requested.
I’m asking for this information it will tell us which CDN node and exactly which HTTP response was incorrect. These details are important in tracking down the reason for the error.
Are you sure there was an SSL error for that exact x-nf-request-id? If so, did they explain how that got that header even though the SSL negotiation failed?
If it was actually a successful pageload, then I would still need the information for an instance where there was an SSL error to troubleshoot.
Hi, @luke . I am 100% certain that the ERR_SSL_PROTOCOL_ERROR happened on this exact x-nf-request-id. I did the request myself on my coworker’s computer. This has never happened when I load up our sites from my computer in Indianapolis IN, so this adds complexity to the situation. Here is a screenshot of what the browser loads when it’s failing …
As for which CDN node … I do not know exactly how to find this. If it is in the same “Response Header” section as the x-nf-request-id, there wasn’t any sort of record that supplied an ip address for the CDN. I have seen on successful pageloads, that the header “server” has a value of Netlify. Will you explain further on how to get this ip address please? Thanks
I have set 3 of my coworkers up with the Opera browser with the built-in vpn set to on and it allows them do their work. However, I’m pretty sure that our clients are experiencing this as well & therefore need to figure out what’s going on.
As always, I appreciate your help on this issue.
Hi, @cmonster52. I do not understand how you got that header:
If there is an SSL error, browsers will close the HTTP connection before any headers are sent. This is why I asked this:
I asked because it is normally impossible to get that header with that error. So, if you did get the header, you must have made some change to allow the HTTPS connection to continue with the invalid SSL certificate. I’m asking what you did to allow that header to be received.
I’m concerned that what occurred is that a second pageload was made that did return a header but that would only happen is SSL succeeded so then I would be looking for issues on the wrong CDN node.
Would you please explain more about how you managed to see that header when the browser should have closed the connection?
I need to know the IP address (which then allows me to know which CDN node caused this) that responded. I’ve tried to determine which browser you are using in the screenshot but I’m not sure which that is. I’ve looked for documentation for how to see the IP address for SSL errors using Chrome and I cannot find the documentation on how to do that.
Personally, I don’t ever troubleshoot SSL issue using browsers (I use a combination of curl and openssl on the command line) specifically because I find browsers themselves not at all useful for troubleshooting these types of issue.
Using curl for example, one can see the IP address returned in the first few lines if the -v (high verbosity) option is used, example below:
$ curl -sv https://admin.successionresource.com/login 2>&1 | head -n 5
* Trying 104.21.95.252...
* TCP_NODELAY set
* Connected to admin.successionresource.com (104.21.95.252) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
The line with “Trying 104.21.95.252…” is where curl shows the IP address.
Also that is a cloudflare IP address not a Netlify IP address. This means it will become much harder for us to troubleshoot as we cannot actually see your full connection. In other words, because you proxy to Netlify, everything downstream between us and Cloudflare and between Cloudflare and the browser becomes much harder (or impossible) for us to see. For example we have a support guide about how proxying to us from Cloudflare blocks SSL certificate provisioning here.
Our recommended DNS configuration for third-party DNS can be found here:
The the recommended DNS record would be the one below (and replacing <site-subdomain-here> with the actual site subdomain under netlify.app):
admin.successionresource.com. 1800 IN CNAME <site-subdomain-here>.netlify.app.
So, I’m not sure how to tell you how to gather the IP address. Personally, I’d just use curl but please use whatever solution you decide is best for you.
Again, unfortunately, even when you do send the IP address information it still may not help me as I still won’t be able to match that IP address to a CDN node at Netlify (because of the Cloudflare proxy).
You could still try to send me this information but I must be clear that while this site is proxied to Netlify from Cloudflare I am greatly limited when troubleshooting these SSL issues.
To reiterate, the information needed is:
Yes, the x-nf-request-id can be used instead but I’ve very hesitant to use those for troubleshooting as I do not yet understand how that header is being gathered during testing.
Last but not least, you might consider not proxying to see if that itself will resolve the issue. Even if it doesn’t it will remove all the limitations that proxying adds to the troubleshooting process.
If there are questions about any of this, let us know and I’ll do my best to answer.