Self-signed wildcard certificate

Question

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?

Answer 1

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.

Answer 2

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).