Pantheon and Public Suffix Domain Failure

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: k12.wa.us

I ran this command:unknown

It produced this output:unknown

My web server is (include version):unknown

The operating system my web server runs on is (include version):unknown

My hosting provider, if applicable, is: Pantheon

I can login to a root shell on my machine (yes or no, or I don’t know): no

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): unknown

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): unknown

Hi! I apologize if this is the wrong topic to post to, and that I don’t have all of this information. I am a Pantheon customer, Pantheon has a process to auto-provision Let’s Encrypt certs when a domain is pointed at Pantheon. We recently launched a site on Pantheon k12.wa.us. This domain is on the public suffix list. Pantheon was able to provision a cert for www.k12.wa.us but we keep getting failures on k12.wa.us. We’ve add a CAA record to k12.wa.us but it still failed to provision the cert. Is there any way we can provision a Let’s Encrypt cert for this domain? Thanks!

Hi @wendywick, welcome to the community forum :wave:

Can you ask Pantheon to share the exact error message they’re receiving from Let’s Encrypt’s ACME API when they try and fail to issue for this domain?

Here is the error from Pantheon.

Domain:k12.wa.us DebugURL: Error:400 urn:acme:error:malformed: Error creating new authz :: Name is an ICANN TLD Valid:false

Also, our domain www.k12.wa.us had a working cert until this morning and is now failing as well.

1 Like

Hi @wendywick

this is a public suffix. So you can’t create a certificate with that domain name, because, it’s not a domain name.

www.k12.wa.us works, that’s a domain (not a subdomain).

So change your setup.

Well, it has been used as a domain name forever, and our customer didn’t even know about the public suffix list. So we need it to have a cert. Other cert providers have worked around it.

I don’t believe the domain causing you problems was previously being used with Let’s Encrypt certificates. I can’t see any certificates issued for exactly k12.wa.us except for three expired Comodo issued certificates from pre 2016. I do see certificates issued by Let’s Encrypt that include www.k12.wa.us but not the bare k12.wa.us that’s causing problems for you now (e.g. this one).

As @JuergenAuer mentioned k12.wa.us is considered a public suffix because it was added to the publicsuffix-list at the request of someone in control of the domain. I thought we had a provision in place to allow issuance for an exact match to a public suffix entry, I will have to look into that and get back to you. It looks like someone affiliated with your organization already considered removing the domain from the PSL and decided against it.

Thank you for your response, you are correct, k12.wa.us has never been used with Let’s Encrypt. We recently launched a new site for this customer on Pantheon (who’s domain has always been k12.wa.us) and since Pantheon utilizes Let’s Encrypt certs this is the first time we’ve run up against this public suffix list issue. We did investigate removing the domain from the public suffix list, but our customer’s domain controller decided against that. We are hoping there is some way to prove ownership of this domain so we can issue a cert for it, even though it’s on the public suffix list. I understand that this is not best practice, but this customer has used this domain since they were created and prior to the public suffix list, so we can’t change our setup at this point.

Thanks!

Hi @wendywick! Welcome to the forum.

This is an interesting case. The public suffix list is broken up into two sections: the ICANN section, and the PRIVATE section. The ICANN section mostly consists of exact TLDs, like com and org, plus effective TLDs like co.uk. We have certain obligations under the Baseline Requirements with regards to public suffixes, mainly that we can’t issue for *.foo where foo is a public suffix.

While those requirements don’t technically prevent us from issuing for TLDs, like com or co.uk, our policy so far has not been to issue for ICANN TLDs because it’s generally not a best practice to put websites on such TLDs. Partly that’s because, for the dotless TLDs, it can create confusion between local network hostnames and global DNS hostnames.

k12.wa.us is in a funny position because it’s listed as a TLD in the ICANN section, but it seems like it is actually being used as a website in addition to a TLD.

So, long story short, this is our current policy. We’re not likely to change it in the short term, but I do appreciate you bringing the instance to our attention since it will help inform our future thoughts on it. I’d recommend getting an inexpensive certificate from another CA if you’d like to continue serving k12.wa.us as a website.

Thanks,
Jacob

Thank you so much for the thorough response and your future consideration of this edge case! We will proceed with an external cert.

Thanks again!

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.