Letsencrypt script pointed to incorrect hostname

ericovk

Verified User
Joined
Apr 17, 2012
Messages
228
Location
Rotterdam, Netherlands
We have a cloned VPS. Hosting provider changed the hostname in the files, like /etc/sysconfig/network and /etc/hostname and also at DA > admin > Administrator settings > hostname.

When I tried to install letsencrypt and set it up for DA admin login, the script is trying to request a certificate on the old hostname (from the original VPS).

It appears the hostname hasn't been changed in -at least- usr/local/directadmin/conf/ca.san_config
But they cannot guarantee the VPS is going to be working correctly when I change this file directly. Does anyone know if this is going to work or not? I don't like downtime on this production machine.
 
Easiest solution, why don't you just create a new letsencrypt certificate on the cloned VPS?
Easy to do and 0 downtime.
 
Hi Richard,

When I start this script, its resolving to the original hostname.

Code:
# ./letsencrypt.sh request righthostname.nl 4096
Setting up certificate for a hostname: righthostname.nl
Getting challenge for [U]original_hostname.nl[/U] from acme-server...
 
Sorry to say you're wrong. This server has been cloned almost a year ago. This server is properly working on righthostname.nl. The only thing that's not working is the Letsencrypt script, as shown above.
 
It seems to me letsencrypt might be remembering the domain name. It's a bit difficult to check things without correct domain names.
Because trix.hosting is right, there is some way Letsencrypt is getting your old hostname from somewhere.

You could try this:
Code:
cd /user/local/directadmin/scripts
./letsencrypt.sh revoke original_hostname.nl
Or maybe revoke original_domainname.nl might be needed.

Then try and create the certificate again.
 
Code:
# ./letsencrypt.sh revoke [COLOR=#333333][FONT=Verdana]original_hostname[/FONT][/COLOR].nl
Setting up certificate for a hostname: [COLOR=#333333][FONT=Verdana]original_hostname[/FONT][/COLOR].nl
Certificate revocation error. Response: HTTP/1.1 100 Continue
Expires: Wed, 14 Jun 2017 12:45:30 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache


HTTP/1.1 404 Not Found
Server: nginx
Content-Type: application/problem+json
Content-Length: 92
Boulder-Request-Id: suxHtHo81AIFhYbiKpkwjOLGfV2b04GzDT6TVQwOWWM
Boulder-Requester: 16680752
Replay-Nonce: tI7dRua6js8mEDLI1XzDHJZtu1jWYzR8-2dRY4MdHuY
Expires: Wed, 14 Jun 2017 12:45:30 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Wed, 14 Jun 2017 12:45:30 GMT
Connection: close


{
  "type": "urn:acme:error:malformed",
  "detail": "No such certificate",
  "status": 404
}.
 
Also tried to revoke domain.nl as I suggested instead of only original_hostname.nl?

You could also check at crt.sh which old certificates still exists. Might make it easier to revoke.
 
I'm not sure if I understand what you're saying.

This server is at subdomain.domain.nl
Domain.nl is pointed to another server (subdomain1.domain.nl), so that would never resolve in the same server as subdomain.domain.nl
 
If you check letsencrypt.sh you can see it determines if it is a request for the server hostname like this:
1. The domain must not be in /etc/virtual/domainowners
2. The domain must be in /etc/virtual/domains
3. The output of "/usr/local/directadmin/directadmin c | grep servername" must match the domain you are requesting it for.

if the certificate you are requesting matches this it'll be treated as a cert for the hostname.

The letsencrypt.sh script will create the san config if it does not yet exist, so you should be able to move it just fine and then request the cert, granted other conditions are met. It's simply re-using the existing SAN, but removing (or editing) it shouldn't matter.
 
If you check letsencrypt.sh you can see it determines if it is a request for the server hostname like this:
1. The domain must not be in /etc/virtual/domainowners
2. The domain must be in /etc/virtual/domains
3. The output of "/usr/local/directadmin/directadmin c | grep servername" must match the domain you are requesting it for.

if the certificate you are requesting matches this it'll be treated as a cert for the hostname.

The letsencrypt.sh script will create the san config if it does not yet exist, so you should be able to move it just fine and then request the cert, granted other conditions are met. It's simply re-using the existing SAN, but removing (or editing) it shouldn't matter.

1. The domain must not be in /etc/virtual/domainowners << righthostname.nl and original_hostname.nl are both not in here
2. The domain must be in /etc/virtual/domains << righthostname.nl is in there, original_hostname.nl is too
3. The output of "/usr/local/directadmin/directadmin c | grep servername" must match the domain you are requesting it for. << only righthostname.nl is in there

Can I just add them in the file? Or do I have to create them through DA somehow?
 
1. The domain must not be in /etc/virtual/domainowners << righthostname.nl and original_hostname.nl are both not in here
2. The domain must be in /etc/virtual/domains << righthostname.nl is in there, original_hostname.nl is too
3. The output of "/usr/local/directadmin/directadmin c | grep servername" must match the domain you are requesting it for. << only righthostname.nl is in there

Can I just add them in the file? Or do I have to create them through DA somehow?

In that case I would simply move /usr/local/directadmin/conf/ca.san_config to another location (as a backup, but it should not be needed) and run ./letsencrypt.sh request $(hostname -f)
to get the new cert :-)
 
Back
Top