My domain is: socomusic.net
I ran this command: certbot renew --dry-run
It produced this output:
Attempting to renew cert (www.socomusic.com ) from /etc/letsencrypt/renewal/www.socomusic.com.conf produced an unexpected error: Unable to find a virtual host listening on port 80 which is currently needed for Certbot to prove to the CA that you control your domain. Please add a virtual host for port 80… Skipping.
My web server is (include version): Apache 2.4.7
The operating system my web server runs on is (include version): Ubuntu 14.04
My hosting provider, if applicable, is: vps.net
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):
The version of my client is (e.g. output of certbot --version
or certbot-auto --version
if you’re using Certbot): 0.28
I got the email that I need to switch away from the TLS version so I upgrade my certbot, but am receiving the error noted above.
In my vhost file, I’m redirecting all of my port 80 traffic to port 443 which I believe is causing the problem, but not sure how to resolve it.
<VirtualHost 68.169.46.243:80>
ServerName socomusic.com
Redirect / https://socomusic.com/
</VirtualHost>
<VirtualHost 68.169.46.243:80>
ServerName www.socomusic.com
Redirect / https://www.socomusic.com/
</VirtualHost>
<VirtualHost 68.169.46.243:80>
ServerName socomusic.net
Redirect / https://socomusic.net/
</VirtualHost>
<VirtualHost 68.169.46.243:80>
ServerName www.socomusic.net
Redirect / https://www.socomusic.net/
</VirtualHost>
Hi @scottismyname
no, this isn't a problem, this is good. But is this really your config file? Or is it the forum software?
<VirtualHost *:80>
DocumentRoot "/www/example1"
ServerName www.example.com
# Other directives here
</VirtualHost>
is the correct version. But there is a second problem (after the redirect - https://check-your-website.server-daten.de/?q=socomusic.com ):
If you use http-01 validation, Certbot creates a file in /.well-known/acme-challenge with a random file name. The redirect to https is ok, that will work. But then follows a http status 403 - Forbidden.
So it's impossible that Letsencrypt can check a file in /.well-known/acme-challenge.
Your server should send a http status 404 - Not found, if the file is unknown.
So check and change your directory permissions.
Thank you for the fast response.
Do I need to create the directory .well-known/acme challenge ??
What permissions should be on the directory?
Also, I’m not sure how to know what format I’m using with this? Do I need to change the configuration file at all? Here is my configuration file:
cert = /etc/letsencrypt/live/www.socomusic.com/cert.pem
privkey = /etc/letsencrypt/live/www.socomusic.com/privkey.pem
chain = /etc/letsencrypt/live/www.socomusic.com/chain.pem
fullchain = /etc/letsencrypt/live/www.socomusic.com/fullchain.pem
version = 0.28.0
archive_dir = /etc/letsencrypt/archive/www.socomusic.com
Options and defaults used in the renewal process
[renewalparams]
installer = apache
authenticator = apache
account = [redacted]
You can create it. Then create a file (file name 1234) and try to load this file with your browser:
http://socomusic.com/.well-known/acme-challenge/1234
The standard 755
permission should be ok.
I did as follows but get forbidden:
Forbidden
You don’t have permission to access /.well-known/acme-challenge/1234 on this server.
Edit: It appears that renaming .well-known to well-known lets me access the file, but obviously that won’t work. So something is blocking access to directories that start with ‘.’ ?
rg305
January 29, 2019, 5:17am
6
I wonder if you can just create a single catch-all http to https vhost config…
With a block like:
<VirtualHost *:80>
ServerName *
Redirect / https://%{HTTP_HOST}/
or
Redirect / https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>
Just a guess: is your HTTPS virtual host using a different IP address from the one specified for the HTTP virtual hosts? or perhaps *:443
or _default_:443
?
I fixed the problem with not being able to access the .well-known, but I’m still getting the same error as above when trying to renew
rg305
February 7, 2019, 10:58pm
9
Can you be a little bit more clear…
Which error above?
I still can’t reach
http://socomusic.com/.well-known/acme-challenge/1234
it returns 404.
Yep, now there is the good http status 404 - Not found:
http://www.socomusic.com/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
68.169.46.243
404
0.320
A
Not Found
But did you find your webroot / DocumentRoot? If yes, then use it:
certbot run -a webroot -i apache -w yourDocumentRoot -d www.socomusic.com -d socomusic.com
I tried running this:
certbot --dry-run renew -a webroot -i apache -w /var/www/skaforey/data/www/socomusic.com
And I get this:
1 renew failure(s), 0 parse failure(s)
IMPORTANT NOTES:
Then this isn't your correct webroot.
As written: Create a file and test it via
http://socomusic.com/.well-known/acme-challenge/1234
to find your correct webroot.
rg305
February 8, 2019, 7:31pm
13
The test file that would correspond to:
http://socomusic.com/.well-known/acme-challenge/1234
Should be located at:
/var/www/skaforey/data/www/socomusic.com/.well-known/acme-challenge/1234
[if that is indeed the correct webroot]
That is indeed the case:
root@socomusic:/var/www/skaforey/data/www/socomusic.com/.well-known/acme-challenge# ls -la
total 12
drwxrwxrwx 2 www-data www-data 4096 Feb 8 11:21 .
drwxrwxrwx 3 www-data www-data 4096 Jan 28 14:57 …
-rwxrwxrwx 1 root root 6 Jan 28 14:55 1234
rg305
February 10, 2019, 12:59am
15
Well it seems like either:
That is not the document root used by that site
The file permissions are keeping the web server from serving it.
This is what I see:
wget http://socomusic.com/.well-known/acme-challenge/1234
–2019-02-10 00:54:51-- http://socomusic.com/.well-known/acme-challenge/1234
Resolving socomusic.com (socomusic.com )… 68.169.46.243
Connecting to socomusic.com (socomusic.com )|68.169.46.243|:80… connected.
HTTP request sent, awaiting response… 404 Not Found
2019-02-10 00:54:51 ERROR 404: Not Found.
Perhaps the web server (error) logs can be of some help.
Or verifying the root folder.
Try:
grep -Eri 'root|host|serverN|serverA|listen|rewrite|direct|incl' /etc/apache2/
I finally figured it out. Previously, based on an above comment, I changed my hard coded IP addresses to be:
<VirtualHost *:80>
My webserver didn’t seem to like that as it stopped redirecting port 80 to port 443 which is why the wget was not working.
I changed it back to contain my IPv4 and IPv6 addresses and now it’s working.
Thank you all!
1 Like
system
Closed
March 12, 2019, 1:11am
17
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.