Certbot client running on a different machine

Help
1

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. crt.sh | 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:
californiaregionalcollaborative.org

I ran this command: certbot renew

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/californiaregionalcollaborative.org.conf

Simulating renewal of an existing certificate for californiaregionalcollaborative.org

Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:
Domain: californiaregionalcollaborative.org
Type: connection
Detail: 164.67.110.64: Fetching http://lsc-acme-cntrl.lsnet.ucla.edu/.well-known/acme-challenge/: Error getting validation data

Hint: The Certificate Authority failed to download the challenge files from the temporary standalone webserver started by Certbot on port 80. Ensure that the listed domains point to this machine and that it can accept inbound connections from the internet.

My web server is (include version):
apache 2.4

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

My hosting provider, if applicable, is:
ON PREMISES

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

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

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

I moved my certbot client from the web server where I created and deployed the SSL certificate to a different vm with no apache installed only certbot . From this vm I can run the command : certbot certificates and I get the correct result :

Found the following certs:
Certificate Name: californiaregionalcollaborative.org
Serial Number: 43f072e829eb58bb0ae77a390256504be2a
Key Type: RSA
Domains: californiaregionalcollaborative.org
Expiry Date: 2022-11-06 20:06:37+00:00 (VALID: 24 days)
Certificate Path: /etc/letsencrypt/live/californiaregionalcollaborative.org/fullchain.pem
Private Key Path: /etc/letsencrypt/live/californiaregionalcollaborative.org/privkey.pem

This VM where I run certbot renew is not the same for the DNS for californiaregionalcollaborative.org and this is why I'm getting the error mentioned before.

My question is : Can I run certbot client from a vm that does not have the DNS authority for the SSL certificate I'm trying to renew and is not a web server?

Googling around I found the article Automate cert renewal from different server which is similar to what I want to run my certbot client except that this vm does not have any web server do the redirect 301 doesn't make it sense to me.

What I want is a central certbot client server where I can perform renewal and deploy these certs to my web farm with an ansible script I already have in place. I'm already doing this using the sectigo ACME automation and I thought that the same concept would apply to this situation.

Thank you for all the help you can provide.

Marcello

2

The ACME challenges are being redirected to a seemingly centralized point:

curl -Ii http://californiaregionalcollaborative.org/.well-known/acme-challenge/Test_File-1234
HTTP/1.1 301 Moved Permanently
Date: Thu, 13 Oct 2022 02:01:18 GMT
Server: Apache
Location: http://lsc-acme-cntrl.lsnet.ucla.edu/.well-known/acme-challenge/
Content-Type: text/html; charset=iso-8859-1

You should be able to use that point to cover your needs:

Note: You will have to run the ACME client on that (redirected) system.

1 Like
3

I tried to run certbot renew from lsc-acme-cntrl.lsnet.ucla.edu but I get the error mentioned in my first post:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/californiaregionalcollaborative.org.conf

Simulating renewal of an existing certificate for californiaregionalcollaborative.org

Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:
Domain: californiaregionalcollaborative.org
Type: connection
Detail: 164.67.110.64: Fetching http://lsc-acme-cntrl.lsnet.ucla.edu/.well-known/acme-challenge/: Error getting validation data

Hint: The Certificate Authority failed to download the challenge files from the temporary standalone webserver started by Certbot on port 80. Ensure that the listed domains point to this machine and that it can accept inbound connections from the internet.

4

The HTTP Challenge to your domain from the Let's Encrypt servers is being redirected incorrectly. For example:

curl -I http://californiaregionalcollaborative.org/.well-known/acme-challenge/ChallengeToken123

HTTP/1.1 301 Moved Permanently
Date: Thu, 13 Oct 2022 02:43:36 GMT
Server: Apache
Location: http://lsc-acme-cntrl.lsnet.ucla.edu/.well-known/acme-challenge/

You redirect it to the ucla.edu domain. Which is fine. But, the challenge token value is lost.

2 Likes
5

this is the code I'm using for my 301 redirect in my virtual host configuration

RewriteRule "^/.well-known/acme-challenge/" "http://lsc-acme-cntrl.lsnet.ucla.edu/.well-known/acme-challenge/$1" [L,R=301]

Do you mean that I have o add some random string at the end? Where do I get the challenge token?

thanks
Marcello

1 Like
6

The challenge token will already be in the URL when it first arrives to your server. You must preserve the challenge token when you redirect it.

You can test your redirect using a curl example like I showed in prior post. I don't often use Apache and don't have a redirect sample to show you. Maybe rg305 will pick up or just check apache docs or google.

3 Likes
7

Got it but on the redirected server lsc-acme-control I’m not running any web server, I’m assuming that the certbot client is suppose to get the redirected challenge code from code from port 80 correct?

Thanks

1 Like
8

Hi @mgiannoni,

This is wrong because the RewriteRule needs to have a regular expression capture group (inside parentheses) to match the token itself. That's what the $1 refers back to. However, since you have no parenthesized capture group, there's nothing for the $1 to expand to in the redirection target.

The version that Certbot uses starts with something similar to

RewriteRule ^/\\.well-known/acme-challenge/([A-Za-z0-9-_=]+)$

4 Likes
9

To clarify the roles of various things here,

  • Certbot connects to the Let's Encrypt server via the ACME API to request your certificate
  • The Let's Encrypt server sends a set of challenges back to Certbot
  • These challenges include HTTP challenges, for which Certbot has to find some way of setting up your web server so that a certain text file will appear at a certain URL (optionally, after following HTTP redirects)
  • Certbot uses plugins and/or hook scripts (that you chose or set up when originally requesting the certificate) to attempt to do this
  • Certbot tells the Let's Encrypt server that the challenges are satisfied
  • The Let's Encrypt server attempts to connect to the site to see if this is correct (if the expected text file is visible at the correct location)
3 Likes
10

thank you for the explanation so I modified the redirect as suggested and now I have :
RewriteRule "^/.well-known/acme-challenge/([A-Za-z0-9-_=]+)$" "http://lsc-acme-cntrl.lsnet.ucla.edu/.well-known/acme-challenge/$1" [L,R=301]

after I run certbot renew from lsc-acme-cntrl.lsnet.ucla.edu (from the log of the apache server where I apply the redirection I see the token code:
23.178.112.107 - - [12/Oct/2022:21:36:31 -0700] "GET /.well-known/acme-challenge/Ea6Rb9iVwTAwLNSkw9vy8NJp8LIEYkTMdscCrwUoLNg HTTP/1.1" 30

then on lsc-acme-cntrl.lsnet.ucla.edu I get this:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/californiaregionalcollaborative.org.conf

Simulating renewal of an existing certificate for californiaregionalcollaborative.org

Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:
Domain: californiaregionalcollaborative.org
Type: connection
Detail: 164.67.110.64: Fetching http://lsc-acme-cntrl.lsnet.ucla.edu/.well-known/acme-challenge/: Error getting validation data

Hint: The Certificate Authority failed to download the challenge files from the temporary standalone webserver started by Certbot on port 80. Ensure that the listed domains point to this machine and that it can accept inbound connections from the internet.

Failed to renew certificate californiaregionalcollaborative.org with error: Some challenges have failed.

I know that port 80 is open on lsc-acme-cntrl.lsnet.ucla.edu because I deactivated the firewall . Am I missing something here?

Thanks
Marcello

1 Like
11

The redirection is now good; But, something is blocking/not accepting the challenge requests:

curl -Ii http://californiaregionalcollaborative.org/.well-known/acme-challenge/Test_File-1234
HTTP/1.1 301 Moved Permanently
Date: Thu, 13 Oct 2022 05:05:17 GMT
Server: Apache
Location: http://lsc-acme-cntrl.lsnet.ucla.edu/.well-known/acme-challenge/Test_File-1234
Content-Type: text/html; charset=iso-8859-1

curl -Ii http://lsc-acme-cntrl.lsnet.ucla.edu/.well-known/acme-challenge/Test_File-1234
curl: (56) Recv failure: Connection reset by peer
3 Likes
12

ok I think I solved the issue thank you to all your inputs very useful.
So I changed the command line to certbot renew --standalone and on the web server where I apply the 301 redirection I have added the same redirection for the https part so that the result configuration is this:

<VirtualHost *:80>
ServerName californiaregionalcollaborative.org
RewriteEngine on
#--MG 101122 added to make the certbot renew on lsc-acme-cntrl.lsnet.ucla.edu
RewriteRule "^/.well-known/acme-challenge/([A-Za-z0-9-_=]+)$" "http://lsc-acme-cntrl.lsnet.ucla.edu/.well-known/acme-challenge/$1" [L,R=301]

    RewriteCond %{HTTPS} off
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

<VirtualHost *:443>
ServerName californiaregionalcollaborative.org

    #--MG 101122 added to make the certbot renew on lsc-acme-cntrl.lsnet.ucla.edu
    RewriteRule "^/.well-known/acme-challenge/([A-Za-z0-9-_=]+)$" "https://lsc-acme-cntrl.lsnet.ucla.edu/.well-known/acme-challenge/$1" [L,R=301]

   </VirtualHost>

and now when I call certbot renew --standalone from the lsc-acme-cntrl.lsnet.ucla.edu I get this:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/californiaregionalcollaborative.org.conf

Simulating renewal of an existing certificate for californiaregionalcollaborative.org

Congratulations, all simulated renewals succeeded:
/etc/letsencrypt/live/californiaregionalcollaborative.org/fullchain.pem (success)

and I can see the downloaded SSL certificate in my /etc/letsencrypt/live/californiaregionalcollaborative.org

The only issue that I have now is that the renewal-hook/post is not getting call after the renewal but this is a different issue that I'll investigate separately from this case.

I want to thank you all here for the help, without your input it would take a very long time to figure this out.

Best
Marcello

2 Likes
13

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