SSL ERR_SSL_UNRECOGNIZED_NAME_ALERT

[bradmatt275]

I'm struggling to get NPM to work with any SSL proxy enabled host.

Everything was working up until a month ago but then I started getting this error:

I have tried the following:

• Using a lets encrypt wild card cert.
• Lets encrypt domain cert.
• Custom RapidSSL certificate.
• Pulling the latest docker image.
• Clearing the docker volume and re-creating

Config:

[LilTrublMakr]

I am also getting the same thing, only on Chrome though. I can open the same sites in FireFox and they will work just fine.

[bradmatt275]

I am also getting the same thing, only on Chrome though. I can open the same sites in FireFox and they will work just fine.

I didn't think to try Firefox but can confirm its the same for me. Only occurs on Chromium based browsers.

[FreddyAbrego]

I'm having the same issue, but I use firefox more. I can CTRL+SHIFT+R for a hard refresh, but that seems to only work for a bit until it starts again.

[seanecoffey]

Same issue but it's unreliable. Only on chrome for me, and sometimes it will briefly work. Had a setup that has worked for ~3 years until this.

I have 3 domains all with the same setup, but only 1 domain exhibits this issue.

I do wonder more if this has something to do with changes to Lets Encrypt and google HSTS or something...?

[Marty-NC-1975]

AM getting the same issue with Chrome only so far. Been using Proxy Manager for years no issues until recently. Seem to get it randomly around my network.

[seanecoffey]

AM getting the same issue with Chrome only so far. Been using Proxy Manager for years no issues until recently. Seem to get it randomly around my network.

Funny you should say that - I have also noticed it's only an issue on my local network, but accessing remotely doesn't seem to be an issue.

[Marty-NC-1975]

AM getting the same issue with Chrome only so far. Been using Proxy Manager for years no issues until recently. Seem to get it randomly around my network.

Funny you should say that - I have also noticed it's only an issue on my local network, but accessing remotely doesn't seem to be an issue.

Agree. Do you have internal DNS server like Pi-Hole or resolve to a public DNS?

[seanecoffey]

AM getting the same issue with Chrome only so far. Been using Proxy Manager for years no issues until recently. Seem to get it randomly around my network.

Funny you should say that - I have also noticed it's only an issue on my local network, but accessing remotely doesn't seem to be an issue.

Agree. Do you have internal DNS server like Pi-Hole or resolve to a public DNS?

Pi-hole internal DNS with unbound. My internal domains are setup in pi-hole to point to NPM. Is this what you use?

[Marty-NC-1975]

AM getting the same issue with Chrome only so far. Been using Proxy Manager for years no issues until recently. Seem to get it randomly around my network.

Funny you should say that - I have also noticed it's only an issue on my local network, but accessing remotely doesn't seem to be an issue.

Agree. Do you have internal DNS server like Pi-Hole or resolve to a public DNS?

Pi-hole internal DNS with unbound. My internal domains are setup in pi-hole to point to NPM. Is this what you use?

Exactly the same as my network

[LilTrublMakr]

Same setup here as well. But I think it is a Chromium based browser issue since everything works in FireFox without issue. But it is strange that I can close Chrome and reopen it and it works for a few minutes. I can also reset my network adaptor and it will work again, for a few minutes.

Of course, mine is currently working right now but I will try and disable PiHole and see if that fixes it. EDIT: Nope.

[zaigham]

try adding these rules in Advanced tab

proxy_ssl_name $host;
proxy_ssl_server_name on;

[jwojtas10]

I have the same issue. I get an SSL error only when I'm connected to pi-hole in my local network. If I enter my website form the internet (from Cloudflare) everything works well. On pihole I have local dns set up to point to npm. My solution is disabling local dns for now and my traffic will go through Cloudflare even form my local network.

[snoopsbne]

Same issue here. Any Chromium browser the issue is present, Firefox is fine. Config has not changed, the error just appeared on all subdomains.

[seanecoffey]

I'm probably jinxing it, but this appears to have resolved itself on one of my domains. Persisting on another one that started having the problem a few days later. Tells me it probably has something to do with Chrome's implementation of HSTS and pre-fetching of SSL certs or something, and not really anything to do with NPM.

[Marty-NC-1975]

I'm probably jinxing it, but this appears to have resolved itself on one of my domains. Persisting on another one that started having the problem a few days later. Tells me it probably has something to do with Chrome's implementation of HSTS and pre-fetching of SSL certs or something, and not really anything to do with NPM.

Agree - I haven't seen it happen all day today. Hopefully you are right

[LilTrublMakr]

Still happening to me for all of my domains unfortunately. My Chrome is up to date as well. I was planning on ditching Chrome when manifest V3 comes out but maybe I'll just make the shift now...

[snoopsbne]

It's happening for me in Edge (so Chromium). I find it hard to believe both Edge and Chrome got the same update at the exactly the same time, but I guess it is possible. It also breaks on Android/chrome as well. I thought it may be due to my split dns only being ipv4 so I did a full ipv6 setup locally and thought I had solved the issue but it randomly the error occurs.

[bradmatt275]

I'm pretty sure this is an issue with ipv6 DNS lookup in Pihole.

I noticed that it was returning an ipv6 address even though I only configured an ipv4 address in local dns:

I had to disable it by adding this line into my dnsmasq.d configuration file:

Since doing that it has been working without any issues.

Although I want to test it for a bit longer before saying for sure that was it.

[JNR8]

This is not an IPv6 issue. At least not for most of us. I can confirm that IPv6 is disabled on my PC and I only resolved IPv4 addresses for my internal server, such as NPM. I am not using PiHole, which leads my to believe it's either a browser or NMP issue. I host several sites through NPM and when this problem happens for one site, other may still work as expected. This is either a Chromium browser issue with the SSL certs provided by Let's Encrypt or it NPM selectively not presenting that certificate or at least presenting it how the browser expects it to be presented.

So far, Edge (my browser of choice) has this issue every 5 mins or so. During this FireFox works as expected.

@zaigham I tried your suggestion, but it made no difference. I believe those options are set by default anyway. But is was worth a try.

[bradmatt275]

This is not an IPv6 issue. At least not for most of us. I can confirm that IPv6 is disabled on my PC and I only resolved IPv4 addresses for my internal server, such as NPM. I am not using PiHole, which leads my to believe it's either a browser or NMP issue. I host several sites through NPM and when this problem happens for one site, other may still work as expected. This is either a Chromium browser issue with the SSL certs provided by Let's Encrypt or it NPM selectively not presenting that certificate or at least presenting it how the browser expects it to be presented.

So far, Edge (my browser of choice) has this issue every 5 mins or so. During this FireFox works as expected.

@zaigham I tried your suggestion, but it made no difference. I believe those options are set by default anyway. But is was worth a try.

It's entirely possible there are multiple issues here.

I have to admit since making that change it has been flawless for me. I was previously getting the error almost 90 percent of the time I attempted to browse to one of the proxy hosts. Then randomly it would work a few times after a lot of refreshing.

I only realized afterwards, but those ipv6 addresses were actually my Cloudflare tunnel IPs. I suspect the browser didn't like that there were two different certificates. My local lets encrypt cert on the ipv4 address and the Cloudflare one on the ipv6 address. Although honestly that is just a guess.

In any case. I will leave the issue open for anyone else still experiencing the problem.

[Marty-NC-1975]

I'm pretty sure this is an issue with ipv6 DNS lookup in Pihole.

I noticed that it was returning an ipv6 address even though I only configured an ipv4 address in local dns:

I had to disable it by adding this line into my dnsmasq.d configuration file:

Since doing that it has been working without any issues.

Although I want to test it for a bit longer before saying for sure that was it.

I was getting similar nslookups for my domains, so i made the same changes as you. Will let you know how it goes

[seanecoffey]

I have never had ipv6 addresses listed by nslookup, so I am not convinced this is/was an ipv6 issue. When I lookup domains either available externally or internally, they both only return ipv4.

By adding address=/example.com/ to the dnsmasq.d conf, this prevents the address from ever being resolved by upstream (external) DNS, which is why it would resolve issues where the internal/external SSL certs do not match.

So I think it is an issue where chrome (or chromium browsers) are fetching SSL certs from the external/public references to the domain and storing these and throwing an error when the internal certs don't match. At least for my case, some specific subdomains only have public proxy (Authelia on auth.domain.com, for example), but most of my domains were only available internally. If i add address=/example.com/ this does resolve my issues, but then prevents me acessing any addresses that are only proxied publicly.

Pi-hole forwards most of my *.domain.com to internal NPM, but sometimes (auth.domain.com) is resolving externally (to "external" NPM) fetching a different SSL certificate - causing chrome to throw an error for my internal domains (theorising).

My issue has resolved itself on some machines (chrome on windows 10, no issues for ~48 hours), but not others (chrome on MacOS) without any changes to setup.

[JNR8]

this happens on addresses that are not externally available.

The browser wont try to load the site from one IP and the SSL from another, so having two addresses returned (IPv4 and IPv6) should not be a problem. The browser will choose one and use it. Plus the SSL certs are linked to the domain name, not the IP address, which should only cause this problem if the domain name was not available to the browser at all. which we can prove is not the case as other browsers (non chromium) work at the same time that this problem occurs.

[ther3zz]

this happens on addresses that are not externally available.

The browser wont try to load the site from one IP and the SSL from another, so having two addresses returned (IPv4 and IPv6) should not be a problem. The browser will choose one and use it. Plus the SSL certs are linked to the domain name, not the IP address, which should only cause this problem if the domain name was not available to the browser at all. which we can prove is not the case as other browsers (non chromium) work at the same time that this problem occurs.

I think what you mentioned kind of makes sense. Locally I have my domain pointed directly to NPM. Externally, the traffic routes though a cloud flare tunnel to NPM. Locally I get that error but externally I'm able to load my domain.

[snoopsbne]

Since properly configuring split DNS for ipv6, so all NPM'ed managed entries have both internal and external IPv6 addresses configured correctly, I've not seen this issue occur.

[aserper]

I'm in the same boat. Started getting this error last week and I don't understand where it's coming from. I too have split DNS setup with addresses from my LAN are resolved to different addresses than in the internet. This setup worked for several years until now

[ther3zz]

I'm in the same boat. Started getting this error last week and I don't understand where it's coming from. I too have split DNS setup with addresses from my LAN are resolved to different addresses than in the internet. This setup worked for several years until now

I actually have not had the issue today. I'm not sure what's up... I did notice though, that when accessing through the internet it seems that cloudflare is using Google Trust Services and the cert used didnt have my domain in there...

[michaelblight]

fwiw in Home Assistant this seems to manifest as a failure to fully load the screen and "retrying in x seconds", along with "websocket connection failed" in the console log. Holding shift during refresh shows the SSL unrecognised error briefly first.

I too run pihole, and nslookup shows two ipv6 addresses along with the expected ipv4 address for npm. I followed the steps in https://github.com/NginxProxyManager/nginx-proxy-manager/issues/3982#issuecomment-2350807730 but put the extra line in a separate file, since pihole overwrites that file. After a pihole restart, nslookup only returns the ipv4 address, so fingers crossed.

[ther3zz]

fwiw in Home Assistant this seems to manifest as a failure to fully load the screen and "retrying in x seconds", along with "websocket connection failed" in the console log. Holding shift during refresh shows the SSL unrecognised error briefly first.

I too run pihole, and nslookup shows two ipv6 addresses along with the expected ipv4 address for npm. I followed the steps in #3982 (comment) but put the extra line in a separate file, since pihole overwrites that file. After a pihole restart, nslookup only returns the ipv4 address, so fingers crossed.

i configured that same thing today (confirmed running nslookup on windows that it was working) and just now got the error so its definitely not that (at least not for me)

[bradmatt275]

fwiw in Home Assistant this seems to manifest as a failure to fully load the screen and "retrying in x seconds", along with "websocket connection failed" in the console log. Holding shift during refresh shows the SSL unrecognised error briefly first. I too run pihole, and nslookup shows two ipv6 addresses along with the expected ipv4 address for npm. I followed the steps in #3982 (comment) but put the extra line in a separate file, since pihole overwrites that file. After a pihole restart, nslookup only returns the ipv4 address, so fingers crossed.

i configured that same thing today (confirmed running nslookup on windows that it was working) and just now got the error so its definitely not that (at least not for me)

It's so strange. I've been running it for a week now after making the change and haven't had the error once.

There doesn't seem to be any consistency in this.

[LilTrublMakr]

Well I think I can confirm that this is definitely a PiHole issue. I spun up a Technitium instance and have not had a single problem in 48 hours. Been wanting to test it out for a minute and now might be the push to do it. It was definitely a lot easier to add a wildcard internal domain.

[JNR8]

Well I think I can confirm that this is definitely a PiHole issue. I spun up a Technitium instance and have not had a single problem in 48 hours. Been wanting to test it out for a minute and now might be the push to do it. It was definitely a lot easier to add a wildcard internal domain.

It’s definitely not a PiHole issue. I do not use PiHole and still have the problem.

The problem is browser related. The browser is requesting a type 65 DNS record (which is either DoH or DoT). If your DNS resolver (PiHole in your case) cannot reply to such requests they will forward them to their upstream DNS servers which will the respond and return back the appropriate IP address, if the record exists. In my case I have internal DNS records that return different IP addresses externally. When this happens the SSL certificate presented to the external traffic is different to the internal one. When a browser already had a session to the site and the SSL certificate changes during that session I believe the browser presents the errors was are seeding.

I suppose you could say that because the browser has now changed its behaviour the issue is that the internal DNS server doesn’t support DNS over HTTPs (DoH) or DNS over TCP (DoT). The solution would be to either configure the browser to stop requesting type 65 DNS record types (which would technically be less secure) or replace the internal DNS server with one that does and provide thy severer with matching SSL certificate from an public Certificate Authority to allow it to successfully response to DoH/DoT requests.

I recently came across the same issue with other devices (phones and tablets) returning my external IP instead of my internal IP even though my internal DNS server was configured on all those devices.

[skprg]

Ok so i was having the same error and i managed to figure out the cause. I was using pihole to resolve my domain to my internal servers IP over my home network but also had a public DNS record pointing to a public proxy server which connected to my internal network over VPN. when i removed the public DNS record the error went away. I am guessing this was because of some mismatch.

[LilTrublMakr]

The problem is browser related. The browser is requesting a type 65 DNS record (which is either DoH or DoT). If your DNS resolver (PiHole in your case) cannot reply to such requests they will forward them to their upstream DNS servers which will the respond and return back the appropriate IP address, if the record exists. In my case I have internal DNS records that return different IP addresses externally. When this happens the SSL certificate presented to the external traffic is different to the internal one. When a browser already had a session to the site and the SSL certificate changes during that session I believe the browser presents the errors was are seeding.

I could be misunderstanding this section (which I probably am), but I don't think this is the case with me. I have 2 domains, a .com and .xyz. Both are registered domains through Cloudflare. My com is available to the outside world but my xyz is internal only. Both are managed by NGINX Proxy Manager with wildcard certs with DNS challenge(?) through Cloudflare and in the case of .com, have a Cloudflare tunnel and then I use Cloudflare to open the subdomains up to the public.

However, for the xyz, I have a wildcard set up in PiHole to go to NPM, and then NPM routes locally. There is a wildcard set up within NPM. These domains are the ones coming up with the browser error and none of them are open to the outside world with the exception of a single subdomain for notifications.

When I do nslooup of any of my xyz domains, they come back to NPM (which is expected since that is where DNS is routing to). I don't understand how the certificates would be mismatched since the domain largely stays internal with the above exception.

EDIT: Grammar

[ther3zz]

Well I think I can confirm that this is definitely a PiHole issue. I spun up a Technitium instance and have not had a single problem in 48 hours. Been wanting to test it out for a minute and now might be the push to do it. It was definitely a lot easier to add a wildcard internal domain.

It’s definitely not a PiHole issue. I do not use PiHole and still have the problem.

The problem is browser related. The browser is requesting a type 65 DNS record (which is either DoH or DoT). If your DNS resolver (PiHole in your case) cannot reply to such requests they will forward them to their upstream DNS servers which will the respond and return back the appropriate IP address, if the record exists. In my case I have internal DNS records that return different IP addresses externally. When this happens the SSL certificate presented to the external traffic is different to the internal one. When a browser already had a session to the site and the SSL certificate changes during that session I believe the browser presents the errors was are seeding.

I suppose you could say that because the browser has now changed its behaviour the issue is that the internal DNS server doesn’t support DNS over HTTPs (DoH) or DNS over TCP (DoT). The solution would be to either configure the browser to stop requesting type 65 DNS record types (which would technically be less secure) or replace the internal DNS server with one that does and provide thy severer with matching SSL certificate from an public Certificate Authority to allow it to successfully response to DoH/DoT requests.

I recently came across the same issue with other devices (phones and tablets) returning my external IP instead of my internal IP even though my internal DNS server was configured on all those devices.

its definitely not that for me. I disabled secure dns in chrome and still get the issue. I also see pihole only returns the ipv4 of my local npm instance (does not return ipv6)

The worst part is I haven't even noticed any logs in npm which link to the session in which the error pops up so I'm having a really hard time tracking this down...

[2StephenWood]

Just to add to the error report... I too am seeing this. I am running PiHole on my local network. I have a mixed set of subdomains, some routed only internally and some proxied through Cloudflare Tunnels to cloudflared which runs on the same server as NPM. I see this error frequently when on my home network, but never once when external. It seems from the reports so far that something has changed in the last few weeks which is causing most browsers to resolve the external IP sometimes and the internal one other times. JNR8's explanation seems the most plausible, but why would this have suddenly changed across so many browsers? It seems some are reproducing the error without pihole on the mix, so that's not the common denominator either. I wonder if it's Cloudflare...? Is anyone reproducing this and not using cloudflare at all? Cloudflare did send an email about changing their automatic SSL/TLS settings as of Sept 9th. This seems a little too coincidental to not be related. Maybe Cloudflare has upgraded our SSL/TLS settings to where our browsers are caching and preferring that over our local DNS now...? The inconsistency is frustrating and makes it hard to trace. I thought it was DoH on Google Chrome, but after disabling "Use secure DNS" in Chrome I experienced the issue again on the following day (double checked the setting when it happened and still disabled).

[stantyan]

I am having the same issue and I am not using a PiHole or Adguard Home. I am have a Unify UDM as my router but NPM was working fine for about a year then suddenly this "ERR_SSL_UNRECOGNIZED_NAME_ALERT" started to appear in Chrome. And it is inconsistent, sometimes I see this error and sometimes the local website loads normally, and also some local domains might work just fine while other local domains show this error "ERR_SSL_UNRECOGNIZED_NAME_ALERT", and they all have the same settings both in Cloudflare and in NPM. In Safari everything works just fine.

[urzz]

It may be caused by chrome default setting DNS-over-HTTPS. Try Modify Chrome Security Config. Set DNS-over-HTTPS to off. It worked for me.

[ther3zz]

It may be caused by chrome default setting DNS-over-HTTPS. Try Modify Chrome Security Config. Set DNS-over-HTTPS to off. It worked for me.

Disabling the secure DNS option actually didn't fix it for me :(