Need Help: Correct SSL-Cert but Error:SSL_ERROR_UNRECOGNIZED_NAME_ALERT

[AlfaJackal]

Successfully installed certificate for dns.domain.com. The problem is, that I will not be redirected to the dns.domain.com/blockpage after clicking a link.

I am able to open the secured site dns.domain.com/blockpage and also dns.domain.com/admin: But if I click on a link, e.g. in a search result in google that leads to a googleadservices.com, I always get an error page in my browser. See screenshot: https://imgur.com/UF1jvzA

Seems not to be an issue but changed my port from 80 to 81 in lightttp. Also doesn't matter if I change blockpage_url in config with or without port.

1. Only one change in config.php: $conf['blockpage_url'] = "https://dns.domain.com:81/blockpage";

2. Changes in external.conf:

   # LETS ENCRYPT + SSL
   $HTTP["host"] == "dns.domain.com" {
   # Ensure the Pi-hole Block Page knows that this is not a blocked domain
   setenv.add-environment = ("fqdn" => "true")
   
   # Enable the SSL engine with a LE cert, only for this specific host
   $SERVER["socket"] == ":443" {
   ssl.engine = "enable"
   ssl.pemfile = "/etc/letsencrypt/live/dns.domain.com/combined.pem"
   ssl.ca-file =  "/etc/letsencrypt/live/dns.domain.com/chain.pem"
   ssl.honor-cipher-order = "enable"
   ssl.cipher-list = "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH"
   ssl.use-sslv2 = "disable"
   ssl.use-sslv3 = "disable"
   }
   
   # Redirect HTTP to HTTPS
   $HTTP["scheme"] == "http" {
   $HTTP["host"] =~ ".*" {
     url.redirect = (".*" => "https://%0$0")
   }
   }
   }

[roenw]

Unfortunately I think this is expected behavior if you have visited the website before and the HSTS header is cached. That prevents the SAN (subject alternative name) of the website from being changed, e.g. to redirect you to a blockpage.

I’ll experiment later and see if I can make it work.

[roenw]

If my findings come up negative, there isn’t much we can do about it. The HSTS header is a website implying that the connection must have maximum security at all times. Personally I feel like it is being misused as its main purpose is to prevent Man-in-the-middle attacks, such as on banks but most Google services now include it.

[AlfaJackal]

Hmm, seems like there is another problem: For example if I open https://analytics.twitter.com, I receive a ssl connection error NSURLErrorDomain.

And if I simple open insecure http://analytics.twitter.com, I will be redirected to my apache. How can that be??

_{Sent with GitHawk}

[roenw]

I'm pretty sure that's the same problem. To solve this issue, I believe you can install the SSL certificate's CA certificate on your device.

This is what OpenDNS users have to do, as their blockpage works in the exact same way, which is DNS hijacking.

[AlfaJackal]

Thanks for your reply.

Edit: With https everything is fine. But I still have that problem of redirecting from http to my apache (port 80) and not to my lighttpd (81). With https every blacklisted page redirects to blockpage.

Do you have any idea?

[roenw]

@AlfaJackal That's very interesting, and it would make sense it would do that if you didn't explicitly specify the port for it to redirect to. If your Apache is running in a non-production environment, you might want to consider just switching its ports with lighttpd, but at the same time I would not reccomend running Pi-Hole, PiPass, lighttpd, and Apache all on one machine in a production environment.

Right now, that's all I can suggest. I'll tell you later on if I come up with anything.

[AlfaJackal]

@AlfaJackal That's very interesting, and it would make sense it would do that if you didn't explicitly specify the port for it to redirect to. If your Apache is running in a non-production environment, you might want to consider just switching its ports with lighttpd, but at the same time I would not reccomend running Pi-Hole, PiPass, lighttpd, and Apache all on one machine in a production environment. ...

@roenw Thank you! Simply changed ports vice versa and everything seem to work now. Will test Let’s encrypt tomorrow and see if it works all together on one Pi.

Permanent solution for the future is to have a single Pi-Hole Pi and the apache separated from that one.

_{Sent with GitHawk}