Wildcard certificates now valid for their non-wildcard form

Wildcard certificates (*.your-domain.tld) generated on Fly are now valid for their non-wildcard form (your-domain.tld).

Before yesterday afternoon, none of our generated wildcard certificates included the non-wildcard hostname. Now they do and you don’t have to change anything. This does not apply to previously generated wildcard certificates, only newly created ones or renewals of previous created ones.

In other words: If you add a *.example.com certificate to your app, it will also be valid for example.com and you don’t have to add a second certificate for your bare domain.

I specifically did not use the term “apex” here to describe the non-wildcard hostname because, even though most aren’t used this way, you can have wildcards that aren’t descendants of an apex hostname (e.g. *.test.example.com, its non-wildcard form is therefore test.example.com).

Why we’re making this change

Over the years, not doing this created a lot of confusion. There is an expectation that a wildcard certificate is valid for it’s non-wildcard form. In practice, that’s not how it works unless you specifically configure it that way when requesting / generating the certificate.

An *.example.com certificate is only really valid for <anything>.example.com, it is not valid for example.com or extra.level.example.com.

So when we figured this would not be a disruptive change it would be a net positive for all our users of wildcard certificates, we just did it.

How does it work?

TLS certificates can be valid for multiple “server names”. In the past, we only supported 1 server name (the same value as the “common name” field) per certificate. That’s still how it works for non-wildcard hostname.

There’s a x509 extension called SAN (Subject Alternative Name) that lets you specify, among other things, alternative “DNS” names a certificate is valid for.

Let’s Encrypt ensures this is valid by testing that all requested names pass the challenge they ask of the user to verify. For wildcard certificates, the only acceptable challenge is the dns-01 challenge. To fulfill the challenge, as a Fly user, you need to point a _acme-challenge CNAME from your non-wildcard hostname’s DNS records to our <gibberish specific to your app>.flydns.net record. This is populated with the latest challenge content required for verification. That’s how Let’s Encrypt knows for sure you control the hostname.

Since the dns-01 challenge’s requirements are the same for the wildcard and non-wildcard hostnames, there is nothing more that our users need to do.

Testing the change from a user’s perspective

OpenSSL’s s_client subcommand allows us to look at the returned certificate. There’s a good chance you already have OpenSSL or LibreSSL installed on your local machine.

echo | openssl s_client -connect checking123.example.com:443 -servername checking123.example.com -showcerts 2>/dev/null | openssl x509 -text

Dissecting the command:

  • We pipe an echo of an empty string into the following command’s STDIN echo |
  • openssl s_client
    • -connect checking123.example.com:443 will resolve the hostname to an IP and tell OpenSSL’s client to connect to it on port 443
    • -servername checking123.example.com is the SNI (Server Name Indicator) that the client will send in its ClientHello
    • -showcerts shows the contents of the certificates returned
    • 2 > /dev/null redirects STDERR to /dev/null (which blackholes the information)
  • | openssl x509 -text parses the input and (piped from the OpenSSL client) as x509 and prints a textual representation.

This should result in something like:

        Version: 3 (0x2)
        Serial Number:
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Let's Encrypt, CN=R3
            Not Before: Feb 16 21:55:19 2023 GMT
            Not After : May 17 21:55:18 2023 GMT
        Subject: CN=*.example.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
            X509v3 Subject Key Identifier:
            X509v3 Authority Key Identifier:

            Authority Information Access:
                OCSP - URI:http://r3.o.lencr.org
                CA Issuers - URI:http://r3.i.lencr.org/

            X509v3 Subject Alternative Name:
                DNS:*.example.com, DNS:example.com
            X509v3 Certificate Policies:
                  CPS: http://cps.letsencrypt.org

                ......v..>.$..M.u.9..X.l].B.z.5.....%.......\pt......G0E. b....[.;.@...+.._8.u..A~....w....!.....d..
%An.*..opk...-....P......v.....|.....=..>.j.g)]...$...4........\pt......G0E.!...UI...8......+.3j.K.]..l.,..f... =.f..s...Q..b.......S....e.U6.r.
    Signature Algorithm: sha256WithRSAEncryption

That’s it for now!


Is it possible this change created an issue to create wildcard certificates? I tried to create one for “*.sportbrook.be”, and I get the correct check for ‘verified’, but the certificate keeps pending, “not been issued yet”. I tried several times by deleting it and trying again, but without success.

(tried both UI and command line)

It did create an issue. I thought I fixed it. Looking into this one now.

1 Like