LetsEncrypt request fails because wrong domain being used in request to LE API

G

gvsteyvo

New member
Joined
Aug 19, 2025
Messages
1
I recently came across this issue that the LetsEncrypt request process (User Level / SSL Certificates) fails because the process uses the data from the
/usr/local/directadmin/data/users/admin/user.conf file to request the certificate at LetsEncrypt, rather than the real domain name I'm requesting the cert for. Let's say the domain is gvsteyvo.be and that the username on the system is gvsteyvo, so it should use the parameters /usr/local/directadmin/data/users/gvsteyvo/user.conf.

In the general /usr/local/directadmin/data/users/admin/user.conf file, the domain name is listed as example.com, so this is what the request to LE looks like when doing it from DA:
Found wildcard domain name and http challenge type, switching to dns-01 validation.
2025/08/19 12:12:25 No key found for account [email protected]. Generating a P256 key.
2025/08/19 12:12:25 Saved key to /usr/local/directadmin/data/.lego/accounts/acme-v02.api.letsencrypt.org/[email protected]/keys/[email protected]
2025/08/19 12:12:25 [INFO] acme: Registering account for [email protected]
2025/08/19 12:12:26 Could not complete registration
acme: error: 400 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-acct :: urn:ietf:params:acme:error:invalidContact :: Error validating contact(s) :: contact email has forbidden domain "example.com"
Failed to issue new certificate
Click to expand...

Which ofcourse is refused.

Any known workarounds (other than me manipulating the admin/user.conf file ofcourse)?
 
Hello,

Is there any chance you used the domain gvsteyvo.be as a hostname? Do you have subdomains created in the domain gvsteyvo.be under other user accounts?

How do you request a new certificate? Do you use command line or directadmin interface? Do you renew an existing certificate? Or request a new one?

In anyway you might try and remove *cert, *cacert, *key files from the directory /usr/local/directadmin/data/users/gvsteyvo/domains/ and try again.
 
Anyone else have an issue with letsencrypt not renewing this week? Trying to find a solution, but not coming up with anything
 
Maybe if you provide your domain name, we might be able to find something.
No issues as far as I know. Your issue can have a totally different cause, so maybe next time start a new topic instead of upping a 6 year old one. ;)
 
Scott DeLeury said:
The domain in question
Click to expand...
As far as I can see there is a wildcard certificate active until december. I see it's activate september 9th so yesterday and valid until december 8th. That happened multiple times yesterday, also for normal certs for ftp,www,mail etc. seperately, all succeeded and are valid.

I also seen that the PTR records is incorrect, it does not point to your hostname.
The hostname has mail.domain.com which is unadvisable to use as hostname in most cases. It can be done but can cause mail issues.
Since the hostname is the same name as your mail record, this might probably be of influence in the LE certificate for the hostname.

So to me everything looks good, maybe indeed answer Zeiter's question what the error notice is.

Personally I would advise to change the hostname to something else than mail, correct the PTR record and then try again.
 
This certificate has expired (7 days ago).

Code: 
Common name: aufieldservices.com
SANs: aufieldservices.com, autodiscover.aufieldservices.com, mail.aufieldservices.com, www.aufieldservices.com, www.autodiscover.aufieldservices.com
Valid from June 5, 2025 to September 3, 2025
Serial Number: 06c287c1154918d5b2ff23e1e850d72caf69
Signature Algorithm: sha256WithRSAEncryption
Issuer: R10

It is a not a wildcard. It is still not clear what the error is. My guess it is related to the redirect from HTTP->HTTPS:

Bash: 
# curl -I http://aufieldservices.com/.well-known/acme-challenge/test.html
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Wed, 10 Sep 2025 17:49:54 GMT
Content-Type: text/html
Content-Length: 162
Connection: keep-alive
Location: https://aufieldservices.com/.well-known/acme-challenge/test.html

Letsencrypt should be able to access the HTTP url on the domain for a verification to complete.
 
Richard G said:
So to me it seems the certificate is upated, but for some reason not implemented in DA, is that a correct assumption?
Click to expand...

If this is the case, then the certificate gets probably attached to another account on the server. Probably there are several accounts on the server with the same domain.
 
This is what I see here also:

1757530156872.png
 
zEitEr said:
Probably there are several accounts on the server with the same domain.
Click to expand...
Not necessarily. If I remember correctly I've seen this happen in the past too with somebody and we fixed that via pm.
He also had a hostname like mail.domain.com and for some reason things got mixed up for LE, don't ask me why. But for this reason I always advise not to use mail for FQDN hostname.
Odd things should not happen but they still do in those cases sometimes.

So I had him create another hostname, the request the hostname certificate again and things worked out. However, then question is why did it work until now. Still odd.

Anyway SSLlabs looks at the server so yes there it's wrong, crt.sh looks at the requested and provided certificates and there all is fine.
 
zEitEr said:
The server's hostname is srv02.dawebhost.net according to DirectAdmin
Click to expand...
I presume you checked that? Then something must be either customized or something went wrong, because Exim is answering with mail.allieduniversalfieldservices.com and normally Exim answers with the hostname.
And PTR points to neither because that points to 173-233-75-3.static.as40244.net.
 
You must log in or register to reply here.
Back
Top