And how do I do that?
So what I’m seeing there is a CloudFlare DDoS production page which is displayed interstitially before loading the site. That’s incompatible with the HTTP-01 authentication used by --webroot
and you’ll need to disable it in order to receive a certificate. (The HTTP-01 authentication expects to see the exact file requested, nothing more and nothing less, and not some JavaScript which is capable of redirecting a browser to that file. The CloudFlare page is serving some JavaScript that redirects JavaScript-capable browsers to the file, eventually.)
There could be other reasons that it’s not working, such as not in fact specifying the correct webroot directory, but that’s likely to be one fatal problem.
Domains behind CloudFlare don’t necessarily need Let’s Encrypt certificates at all because CloudFlare can provide a publicly-trusted certificate to user, and can provide a CloudFlare-trusted certificate to you that you can install to protect the connection between CloudFlare and your origin server.
I disabled cloudflare for bell-computing.com and ran the expand certificate command again but still get the same unauthorised failure and it doesn’t add the new site. Do I need to completely remove Bell-computing.com from Cloudflare? Or is it a different issue?
Failed authorization procedure. www.bell-computing.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.bell-computing.com/.well-known/acme-challenge/9gzhL4VPq_VQwODnHJ1V4dm5hynICOznTxj_Oa0MQTg: "
<meta http-equiv="Content-Type" content="text/html; char", bell-computing.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://bell-computing.com/.well-known/acme-challenge/BxIMlRUhTJORRPyg4kPi-CwWz51z6TWuG2Yngy8PJCs: " <meta http-equiv="Content-Type" content="text/html; char"IMPORTANT NOTES:
-
The following errors were reported by the server:
Domain: www.bell-computing.com
<meta http-equiv="Content-Type" content="text/html; char"
Type: unauthorized
Detail: Invalid response from
http://www.bell-computing.com/.well-known/acme-challenge/9gzhL4VPq_VQwODnHJ1V4dm5hynICOznTxj_Oa0MQTg:
"Domain: bell-computing.com
<meta http-equiv="Content-Type" content="text/html; char"
Type: unauthorized
Detail: Invalid response from
http://bell-computing.com/.well-known/acme-challenge/BxIMlRUhTJORRPyg4kPi-CwWz51z6TWuG2Yngy8PJCs:
"To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address.
Can you look in your own server logs to see if you can see a request for this file? That might at least show whether the request actually reached your server.
Not sure if I am looking at the right logs. in /var/logs neither auth.log nor syslog contain that file name.
CloudFlare is still in the way—you can see this if you try a fresh browser or browser profile.
I couldonly disable Cloudflare for a couple of hours, the dns is configured for my mail service too.But it was disabled when I tried. If you give me a time say 14.00gmt I could make sure its disabled then if that’ll help troubleshoot?
It looks fine to me in in Edge, which I havent accessed it in, or Incogito Chrome with cookies and cache cleared fwiw.
The usual way of testing this is to make a file called test.txt
in .well-known/acme-challenge
under your webroot (e.g. /srv/users/serverpilot/apps/wordpress/public/.well-known/acme-challenge/test.txt
) and then see if you can see http://www.bell-computing.com/.well-known/acme-challenge/test.txt in a browser. If you can’t, then the webroot you specified isn’t really your webroot, or your web server is set up in a way that’s incompatible with the ACME HTTP-01 challenge.
First of all I couldn’t copy test.txt into the.well-known folder, insufficient permission Filezilla said. So I deleted the folder and recreated, but the acme-challenge wasn’t there (its a folder I presumed so I also created it as acme-challenge under .well-known). Your link to my webroot now works. But if I run the expand command again the authentication error now also says it can’t clean up acme-challenge.
So, I thought you would use command line tools to create the file rather than a remote file manager; I don’t know how the accounts and file permissions work on your server. The “can’t clean up” error is just because you’ve created an additional file there and that doesn’t cause any harm.
CloudFlare is, however, still in the way so we wouldn’t expect this to work in any case. You can see this with
curl http://www.bell-computing.com/.well-known/acme-challenge/test.txt
As long as that continues to display CloudFlare stuff instead of the contents of your test file, the challenge will fail as well.
I'm not seeing anything but the contents of test.txt, nothing about cloudflare.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
curl http://www.bell-computing.com/.well-known/acme-challenge/test.txt
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
But I am still seeing the authentication error
I still see the CloudFlare code there, not the contents of your file. Maybe it serves different things to different source IP addresses?
OK I redirected my dns and managed to install the cert for paulmarshallcarpetsandflooring.bell-computing.com. At least it shows in certbot certificates but still shows a certificate mismatch in qualys. Is that a matter of waiting?
Do you have a sample of the cloudflare stuff so I can take it up with them, I would like to use cloudflare if possible
If I renable how can I tell if its causing a problem again?
Thanks for all your help.
Nope, it's a matter of configuring nginx to use that certificate! Just having a copy of it on your computer won't do anything. If you configure it in nginx, it will work right away; if you don't, it will never work.
I can send you a private message with an example of what it returns. I'm not certain that this is the reason that the certificate issuance is failing, but it's definitely sufficient to prevent certificate issuance if they also serve this to the CA when it comes to perform the test.
So how do I configure it in nginx then? Because my /etc/nginx-sp/vhosts.d contains myappname.ssl.conf with the server name including the new certificate.
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name
178.62.53.135
bell-computing.com
cle-france.bell-computing.com
cle-france.com
cle.bell-computing.com
en.bell-computing.com
fr.bell-computing.com
mg.bell-computing.com
paulmarshallcarpetsandflooring.bell-computing.com
staging.bell-computing.com
www.bell-computing.com
www.cle-france.bell-computing.com
www.cle-france.com
;
root /srv/users/serverpilot/apps/wordpress/public;
ssl on;
# letsencrypt certificates
ssl_certificate /etc/letsencrypt/live/bell-computing.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/bell-computing.com/privkey.pem;
#SSL Optimization
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:20m;
ssl_session_tickets off;
# modern configuration
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';
# OCSP stapling
ssl_stapling on;
ssl_stapling_verify on;
# verify chain of trust of OCSP response
ssl_trusted_certificate /etc/letsencrypt/live/bell-computing.com/chain.pem;
#root directory and logfiles
root /srv/users/serverpilot/apps/wordpress/wordpress_nginx/public;
access_log /srv/users/serverpilot/log/wordpress/wordpress_nginx.access.log main;
error_log /srv/users/serverpilot/log/wordpress/wordpress_nginx.error.log;
#proxyset
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-SSL on;
proxy_set_header X-Forwarded-Proto $scheme;
#includes
include /etc/nginx-sp/vhosts.d/wordpress.d/*.nonssl_conf;
include /etc/nginx-sp/vhosts.d/wordpress.d/*.conf;
}
Hmmm!
Did you reload nginx after obtaining the certificate? (Certbot doesn’t do that for you if you use --webroot
.)
Is /etc/letsencrypt/live/bell-computing.com/fullchain.pem
where it told you that it saved the new certificate that included the paulmarshallcarpetsandflooring.bell-computing.com
name?
What do you see if you run
openssl x509 -text -noout -in /etc/letsencrypt/live/bell-computing.com/cert.pem
now?
No but I just stopped it but it errors now on trying to start it. The logs suggest I restarted too soon but the failure now seems permanent, because after 5 mins it still fails.
root@bell-computing:~# sudo service nginx-sp start
Job for nginx-sp.service failed because the control process exited with error code. See “systemctl status nginx-sp.service” and “journalctl -xe” for details.
root@bell-computing:~# ^C
root@bell-computing:~# systemctl status nginx-sp.service
● nginx-sp.service - nginx-sp
Loaded: loaded (/lib/systemd/system/nginx-sp.service; enabled; vendor preset: enabled)
Active: inactive (dead) (Result: exit-code) since Mon 2017-10-30 17:19:33 UTC; 34s ago
Process: 2150 ExecStartPre=/opt/sp/nginx/sbin/nginx -t (code=exited, status=1/FAILURE)
Oct 30 17:19:31 bell-computing.com systemd[1]: nginx-sp.service: Control process exited, code=exited status=1
Oct 30 17:19:31 bell-computing.com systemd[1]: Failed to start nginx-sp.
Oct 30 17:19:31 bell-computing.com systemd[1]: nginx-sp.service: Unit entered failed state.
Oct 30 17:19:31 bell-computing.com systemd[1]: nginx-sp.service: Failed with result ‘exit-code’.
Oct 30 17:19:33 bell-computing.com systemd[1]: nginx-sp.service: Service hold-off time over, scheduling restart.
Oct 30 17:19:33 bell-computing.com systemd[1]: Stopped nginx-sp.
Oct 30 17:19:33 bell-computing.com systemd[1]: nginx-sp.service: Start request repeated too quickly.
Oct 30 17:19:33 bell-computing.com systemd[1]: Failed to start nginx-sp.
root@bell-computing:~# ^C
root@bell-computing:~# journalctl -xe
– Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
– Unit nginx-sp.service has failed.
– The result is failed.
Oct 30 17:19:31 bell-computing.com systemd[1]: nginx-sp.service: Unit entered failed state.
Oct 30 17:19:31 bell-computing.com systemd[1]: nginx-sp.service: Failed with result ‘exit-code’.
Oct 30 17:19:33 bell-computing.com systemd[1]: nginx-sp.service: Service hold-off time over, scheduling restart.
Oct 30 17:19:33 bell-computing.com systemd[1]: Stopped nginx-sp.
– Subject: Unit nginx-sp.service has finished shutting down
– Defined-By: systemd
– Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
– Unit nginx-sp.service has finished shutting down.
Oct 30 17:19:33 bell-computing.com systemd[1]: nginx-sp.service: Start request repeated too quickly.
Oct 30 17:19:33 bell-computing.com systemd[1]: Failed to start nginx-sp.
– Subject: Unit nginx-sp.service has failed
– Defined-By: systemd
– Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
– Unit nginx-sp.service has failed.
– The result is failed.
Your openssl command gives me
Found the following certs:
Certificate Name: bell-computing.com
Domains: bell-computing.com cle-france.bell-computing.com cle-france.com cle.bell-computing.com en.bell-computing.com fr.bell-computing.com paulmarshallcarpetsandflooring.bell-computing.com staging.bell-computing.com www.bell-computing.com www.cle-france.bell-computing.com www.cle-france.com www.cle.bell-computing.com www.en.bell-computing.com www.fr.bell-computing.com
Expiry Date: 2018-01-28 13:44:16+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/bell-computing.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/bell-computing.com/privkey.pem
root@bell-computing:~# sudo service nginx-sp start
Job for nginx-sp.service failed because the control process exited with error code. See “systemctl status nginx-sp.service” and “journalctl -xe” for details.
root@bell-computing:~# openssl x509 -text -noout -in /etc/letsencrypt/live/bell-computing.com/cert.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
03:12:51:5a:4f:83:17:7a:77:e7:78:87:ed:92:aa:d8:fc:0b
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Let’s Encrypt, CN=Let’s Encrypt Authority X3
Validity
Not Before: Oct 30 13:44:16 2017 GMT
Not After : Jan 28 13:44:16 2018 GMT
Subject: CN=bell-computing.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c2:b3:7a:29:dc:54:59:c7:94:84:39:cb:55:13:
e1:78:44:3c:e1:d8:77:32:ba:3f:dd:42:9f:c3:b9:
d9:12:69:25:62:1d:57:5e:3f:c7:b3:f3:a1:1a:e0:
18:2f:83:0f:69:1a:18:d0:e7:1c:89:d9:3e:69:b7:
b7:cd:eb:73:8f:e6:45:c0:5b:4f:5a:f3:70:40:ff:
67:e9:eb:79:06:1b:b0:d0:79:3b:26:47:1b:e6:e0:
d3:38:2d:84:17:17:16:8c:f6:36:42:9e:0b:ec:59:
eb:7f:c5:71:fd:f0:ef:2f:71:57:22:de:00:72:bd:
2a:73:e0:63:f9:9b:46:a7:f7:1d:e2:b9:1d:f8:5a:
a5:ee:6c:59:dd:78:45:6b:61:b3:d0:b9:e0:16:1a:
f4:50:ae:3c:34:51:56:93:9a:f1:c0:60:07:53:fe:
bf:cb:d2:7e:d4:6a:11:2e:f2:8b:d4:c6:46:29:e7:
dd:63:61:05:15:1b:39:22:84:5e:9b:c1:21:4e:f0:
b3:1f:64:5b:f3:ef:61:49:e6:a0:36:be:4c:c7:2e:
d1:50:72:a8:2f:07:ec:46:cf:e1:dc:dc:e9:65:0c:
44:b1:fe:20:21:43:57:39:a5:ec:b3:80:6c:13:04:
28:9b:16:70:0c:c1:1c:a4:03:46:f9:3e:06:f3:ec:
a2:cf
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
72:8E:A0:5B:61:9D:20:21:DD:0C:99:5E:95:4F:25:53:65:03:35:B1
X509v3 Authority Key Identifier:
keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1
Authority Information Access:
OCSP - URI:http://ocsp.int-x3.letsencrypt.org
CA Issuers - URI:http://cert.int-x3.letsencrypt.org/
X509v3 Subject Alternative Name:
DNS:bell-computing.com, DNS:cle-france.bell-computing.com, DNS:cle-france.com, DNS:cle.bell-computing.com, DNS:en.bell-computing.com, DNS:fr.bell-computing.com, DNS:paulmarshallcarpetsandflooring.bell-computing.com, DNS:staging.bell-computing.com, DNS:www.bell-computing.com, DNS:www.cle-france.bell-computing.com, DNS:www.cle-france.com, DNS:www.cle.bell-computing.com, DNS:www.en.bell-computing.com, DNS:www.fr.bell-computing.com
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.44947.1.1.1
CPS: http://cps.letsencrypt.org
User Notice:
Explicit Text: This Certificate may only be relied upon by Relying Parties and only in accordance with the Certificate Policy found at https://letsencrypt.org/repository/
Signature Algorithm: sha256WithRSAEncryption
3d:04:5a:86:39:f3:5d:d2:48:02:cf:76:81:02:b7:85:4e:2c:
b4:26:99:63:78:55:64:53:50:71:c4:15:f2:b5:54:28:0b:8b:
8b:ca:ae:b6:b3:f0:c2:0c:1c:80:d7:a8:73:81:af:a4:09:4c:
22:ab:8f:9a:2c:ec:4d:87:48:ee:99:1b:71:dd:f8:0a:f1:ef:
bb:e5:be:91:ba:a2:49:4b:88:5d:de:be:bd:27:fe:08:96:63:
05:cc:83:25:0f:50:01:a1:a1:07:44:5e:3f:90:09:a0:0c:bd:
ff:30:90:62:bd:d1:54:a6:a2:60:cd:7c:55:d1:dc:ea:1a:f8:
b8:64:12:ab:0f:9b:62:e2:dd:68:1b:3a:6a:ba:ae:2b:37:37:
5c:7b:7a:33:5d:55:99:cd:e9:d5:fd:04:99:16:59:f6:e4:fc:
ab:8f:09:16:f4:73:c3:c1:e6:c5:16:bc:9f:66:69:97:e6:9d:
ae:f8:84:5f:2b:e6:e6:e8:98:ab:66:94:fd:50:74:d3:76:de:
fe:66:c0:95:2e:79:d5:71:8a:0e:6b:08:44:fc:d3:0d:62:53:
50:ff:13:c9:a1:cf:61:b4:34:8c:3b:b1:c5:d7:2e:a9:20:f2:
f0:bc:2c:41:40:c5:c6:fb:df:63:cf:30:34:9c:04:41:0c:47:
97:bc:d1:ab
root@bell-computing:~#
Well, I guess if you can get your nginx up again, it should see the new certificate with the additional name.
Any ideas how to get it up again? sudo service nginx-sp start just continued to give me the failure