Public Suffix for .work


#1

I have a .work domain (that appears on the PSL) that I am not able to get a certificate for. I’ve tried using the built-in module in PfSense and the module in FreePBX. Is this really related to a prohibition on the domain or rather is there some other problem?

Here are the relevant sections of the logfile for the PfSense attempt:

[Fri Apr 14 00:32:33 EDT 2017] _ret=‘0’
[Fri Apr 14 00:32:33 EDT 2017] original=’{“type”: “urn:acme:error:malformed”, “detail”: “Error creating new authz :: Name does not end in a public suffix”, “status”: 400}’
[Fri Apr 14 00:32:33 EDT 2017] responseHeaders='HTTP/1.1 100 Continue

and

[Fri Apr 14 00:32:33 EDT 2017] response=’{“type”:“urn:acme:error:malformed”,“detail”:“Error creating new authz :: Name does not end in a public suffix”,“status”: 400}’
[Fri Apr 14 00:32:33 EDT 2017] code=‘400’
[Fri Apr 14 00:32:33 EDT 2017] The new-authz request is ok.
[Fri Apr 14 00:32:33 EDT 2017] new-authz error: {“type”:“urn:acme:error:malformed”,“detail”:“Error creating new authz :: Name does not end in a public suffix”,“status”: 400}
[Fri Apr 14 00:32:33 EDT 2017] pid
[Fri Apr 14 00:32:33 EDT 2017] No need to restore nginx, skip.
[Fri Apr 14 00:32:33 EDT 2017] _clearupdns
[Fri Apr 14 00:32:33 EDT 2017] Dns not added, skip.
[Fri Apr 14 00:32:33 EDT 2017] _on_issue_err

Thanks for your help.


#2

Can you show me the domain ?


#3

The domain is: schunet.work


#4

The .work suffix is ok.

there must be something wrong with pfSense module UI, Please report issues in the pfSense forum.

I’m the author of the https://acme.sh project, which is used as the implementation of the pfSense module.

Can you please login to your server , then install acme.sh and try to issue a cert with acme.sh directly.


#5

It does look like over 45,000 Let’s Encrypt certificates have already been issued for .work names

https://crt.sh/?Identity=%.work&iCAID=16418

So it doesn’t seem like Let’s Encrypt fails to recognize this as a valid public suffix in the usual case, unless something has abruptly changed.


#6

I believe there are more logs you aren’t sharing that highlight the true issue here. As pointed out by @schoen and @Neilpang there’s no reason you would get this error for "schunet.work".

Looking at the server side logs, I do see this error for a request to create an authorization for "the.schunet.schu" which, as reported, does not end in a public suffix.

Can you check your Acme.sh config & the way you are invoking it to make sure you are only providing valid domain names?


#7

I got it! The problem ended up being with NAT redirection. The error threw me off and had me going down the wrong road. Knowing that the error wasn’t truly the .work domain me to look into other problems.

Thanks, everybody, for your help. The quick, knowledgeable responses were better than I’ve received from most paid products. Very impressive!


#8

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