I've got pihole set up at home, so I want to be able to handle requests for any website with my own server, to show a "this site has been blocked" page.

I'm attempting to do this by creating a self-signed certificate for any url and installing this on my device. The commands I used to generate the certificate:

openssl genrsa 2048 > pihole.key
openssl req -new -x509 -nodes -days 36500\
    -key pihole.key \
    -subj "/C=NL/ST=Utrecht, Inc./CN=*" \
    -reqexts SAN \
    -config <(cat /etc/ssl/openssl.cnf \
        <(printf "\n[SAN]\nsubjectAltName=DNS:*,DNS:*")) \
    -out pihole.cert
openssl x509 -noout -fingerprint -text < pihole.cert > pihole.info
cat pihole.cert pihole.info > pihole.pem
service apache2 reload

I've installed this certificate on my windows device, and windows shows that it's a valid certificate.

However, chrome gives me a NET::ERR_CERT_COMMON_NAME_INVALID, and edge gives me a similar error (DLG_FLAGS_SEC_CERT_CN_INVALID)

Why is this? Is CN = * just not allowed? How could I achieve what I want?

  • As a side note: For major websites your browser will probably not accept any certificate you manage to generate. Those sites use certificate-pinning and submit fingerprints of their TLS certs for inclusion in those browsers. Your cert won't match the stored fingerprint and will be blocked. Here's more info: noncombatant.org/2015/05/01/about-http-public-key-pinning – Martijn Heemels Nov 13 at 12:44
  • self signed certs can be problematic as you have discovered. You could instead look at getting a "proper" certification from letsencrypt.org - they are free and support wildcards. Depending on how many of the hosts you were trying to cover with that * you actually need, one (or more) certs from letsencrypt could cover you – Dave Smylie Nov 13 at 22:30
  • 1
    @DaveSmylie it's for an adblocker, I don't own the domains. – Daniël van den Berg Nov 14 at 5:53
  • letsencrypt.org will give you signed certs for free – Stewart Nov 14 at 10:43
  • 1
    Also of note: if you're using this for an adblocker, it might be better to just silently drop the connections to relevant servers instead of showing an alternative page. 90% of modern ads are initially loaded through JavaScript, so it's unlikely your alternative page is going to have any real visibility on the page. It's probably going to break stuff, actually, trying to load non-JavaScript resources as Javascript. – Nzall Nov 14 at 14:13
up vote 35 down vote accepted

It is not allowed. As a protocol-specific addition to the standard TLS hostname validation, all major web browsers (HTTPS clients) have basically agreed to restrict wildcard certificates to "eTLD+1" – that is, there must be an "effective TLD" plus one more non-wildcard component.

Generally this translates to requiring at least two components (*.example.net is okay but *.net is not, neither is a bare *). The "effective TLD" rule expands this to multi-level suffixes as co.uk that people use as indivisible "TLDs" in practice. (So *.example.ac.uk is allowed but *.ac.uk is not.)

You can inspect how the public suffix list is implemented in Chromium and in Mozilla.

See related discussion in Security.SE which has a quote from the CA-Browser Forum Baseline Requirements (which only apply to public WebPKI CAs, but still reflect the general implementation anyway):

CAs SHALL revoke any certificate where wildcard character occurs in the first label position immediately to the left of a “registry‐controlled” label or “public suffix”.

To avoid this restriction, build a certificate authority that issues certificates "on demand" for whatever website you try to visit. I don't know how that would be implemented in any regular web server, but this is a common method used by commercial TLS interception systems; antivirus programs and other malware; and development tools such as the Burp Proxy suite.

For example, the OpenResty web server (basically Nginx-with-Lua) has a ssl_certificate_by_lua option to implement dynamic certificate generation. The Squid proxy supports certificate mimicking in its ssl-bump feature.

Also note that SANs completely override the Subject-CN if both are present. This makes including the CN mostly redundant (unless your client software is so ancient it lacks SAN support), and for public CAs web browsers don't even accept it anymore.

  • I already found about that TLD+1 limit empirically here in a project earlier on. Thanks for laying it out. +1 – Rui F Ribeiro Nov 13 at 12:32
  • Thanks for your elaborate answer, I guess that explains it yeah. Do you happen to know a different approach that I could use? – Daniël van den Berg Nov 13 at 13:08
  • 21
    Upvoted for strategic placement of "and other malware". – Džuris Nov 13 at 16:12
  • @DaniëlvandenBerg: I happen to have suggested one in the post itself. I've just added links to Nginx and Squid examples. – grawity Nov 14 at 9:05

There can only be a single wildcard in a certificate (i.e. no *.*.example.com), it can match only a single label (i.e. only www, not www.example.com), it can only be on the leftmost position (i.e. *.www.example.com but not www.*.example.com) and it cannot be inside the public suffix (i.e. no *.com).

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.