3

I have a domain through AWS Route 53,

the Primary domain was secured via letsencrypt methods, but were not working for any wildcard / subdomains...

I tried to redo the cert with the *.example.com domain and the DNS TXT verification method in the records. This worked on my endpoints that are GeoDNS routed to their particular instances, i.e. fr.example.com and us.example.com ... but now when I go to my primary domain example.com it now says it's not secured (anymore), and much of my code referencing this primary domain errors because of "invalid cert".

When I load this primary domain via Chrome browser, it reports "Not Secure", and when I click it, to see the Certificate: (Not Secure) and I'll click on that, the details pop up, shows my *.example.com domain, but lit up green saying that domain IS secure. ...?

In Safari it says *.example.com certificate name does not match input.

Any Ideas whats wrong? How can I secure my primary domain with the wildcards being secured as well?

mrSidX
  • 143
  • 1
  • 7

1 Answers1

8

The wildcard name on the certificate only matches the subdomains. To secure the "naked" domain, you need to add that name separately to the Subject Alternative Name list.

Some of the restrictions in regards to wildcard certificates are explained in this post.

Wildcard certificates

The V2 API supports issuing wildcard certificates. To request a wildcard certificate simply send a wildcard DNS identifier in the newOrder request. Under Let’s Encrypt’s policy, wildcard identifiers must be validated by a DNS-01 challenge, so order authorizations corresponding to wildcard identifiers will only offer a DNS-01 challenge. DNS names in certificates may only have a single wildcard character, and it must be the entire leftmost DNS label, for instance *.example.com. A single certificate can have wildcard DNS names for multiple base domains, and can also mix in non-wildcard names.

Orders that contain both a base domain and its wildcard equivalent (e.g. *.example.com and example.com) are valid. In that case, there will be two authorization objects in the order for example.com, one of which represents the wildcard validation and one of which represents the base domain validation. Redundant entries will produce an error. For instance, and order containing both *.example.com and www.example.com would produce an error since the wildcard entry makes the latter redundant.

And in reference to wildcard certificates in general, while wikipedia is not a reliable source to quote, the example given there is accurate.

A single wildcard certificate for https://*.example.com will secure all these subdomains on the https://*.example.com domain:

  • payment.example.com
  • contact.example.com
  • login-secure.example.com
  • www.example.com

...

Because the wildcard only covers one level of subdomains (the asterisk doesn't match full stops), these domains would not be valid for the certificate:

  • test.login.example.com

The "naked" domain is valid when added separately as a Subject Alternative Name:

  • example.com

Note possible exceptions by CAs, for example wildcard-plus cert by DigiCert contains an automatic "Plus" property for the naked domain example.com.

chutz
  • 7,888
  • 1
  • 29
  • 59
  • Thanks... I was using an older version of ```certbot```, after update to newer version I was able to ```-d *.example.com example.com``` in the parameters... Updated the cert in my server's config files and it was good to go. Thanks again! – mrSidX Dec 22 '20 at 01:18
  • 1
    just to clarify, that would be `-d '*.example.com' -d example.com` - the `-d` must be repeated for each domain & the `*` means the wildcard request needs to be in single quotes to stop the shell expanding it to file names! – James Stevens May 12 '22 at 14:13