Прошу помощи с решением проблемы.
Вероятно где-то ошибся и накосячил.
Мы меняем местами сервера — боевой и копию.
Чтобы хватало места под папку upload (на боевом нет возможности расширить).
Попробовали добавить поддомен на копию (была some.copy.site.ru — добавили some.copy2.site.ru), чтобы потом some.copy.site.ru перенести туда где сейчас боевой, а some.copy2.site.ru заменить на some.site.ru — сделать боевым.
Стали отрываться оба поддомена ведущий на один портал. Один по https, другой по http.
При попытке добавить SSL на второй поддомен — всё сломалось.
Теперь nginx не стартует.
# systemctl start nginx.service
Job for nginx.service failed because the control process exited with error code. See «systemctl status nginx.service» and «journalctl -xe» for details.
# systemctl status nginx.service
● nginx.service — nginx — high performance web server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Fri 2022-01-07 13:02:55 +04; 46s ago
Docs: http://nginx.org/en/docs/
Process: 11094 ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf (code=exited, status=1/FAILURE)
Jan 07 13:02:55 centos-79-64-minimal systemd[1]: Starting nginx — high performance web server…
Jan 07 13:02:55 centos-79-64-minimal nginx[11094]: nginx: [emerg] cannot load certificate «/etc/letsencrypt/live/some….
Jan 07 13:02:55 centos-79-64-minimal nginx[11094]: nginx: configuration file /etc/nginx/nginx.conf test failed
Jan 07 13:02:55 centos-79-64-minimal systemd[1]: nginx.service: control process exited, code=exited status=1
Jan 07 13:02:55 centos-79-64-minimal systemd[1]: Failed to start nginx — high performance web server.
Jan 07 13:02:55 centos-79-64-minimal systemd[1]: Unit nginx.service entered failed state.
Jan 07 13:02:55 centos-79-64-minimal systemd[1]: nginx.service failed.
Hint: Some lines were ellipsized, use -l to show in full.
# journalctl -xe
—
— Unit session-178.scope has finished starting up.
—
— The start-up result is done.
Jan 07 13:05:01 centos-79-64-minimal systemd[1]: Started Session 179 of user root.
— Subject: Unit session-179.scope has finished start-up
— Defined-By: systemd
— Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
—
— Unit session-179.scope has finished starting up.
—
— The start-up result is done.
Jan 07 13:05:01 centos-79-64-minimal systemd[1]: Started Session 180 of user bitrix.
— Subject: Unit session-180.scope has finished start-up
— Defined-By: systemd
— Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
—
— Unit session-180.scope has finished starting up.
—
— The start-up result is done.
Jan 07 13:05:01 centos-79-64-minimal CROND[11297]: (root) CMD (/opt/webdir/bin/restart_httpd-scale.sh process)
Jan 07 13:05:01 centos-79-64-minimal CROND[11298]: (root) CMD (/opt/webdir/bin/update_network.sh eno1)
Jan 07 13:05:01 centos-79-64-minimal CROND[11299]: (bitrix) CMD (test -f /home/bitrix/www/bitrix/modules/main/tools/cronJan 07 13:05:01 centos-79-64-minimal CROND[11300]: (bitrix) CMD (/usr/bin/php -f /home/bitrix/www/bitrix/php_interface/cJan 07 13:05:01 centos-79-64-minimal systemd[1]: Removed slice User Slice of bitrix.
— Subject: Unit user-600.slice has finished shutting down
— Defined-By: systemd
— Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
—
— Unit user-600.slice has finished shutting down.
Jan 07 13:05:05 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:aJan 07 13:05:07 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:aJan 07 13:05:08 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:aJan 07 13:05:09 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:aJan 07 13:05:12 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:aJan 07 13:05:13 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:aJan 07 13:05:13 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:aJan 07 13:05:13 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:aJan 07 13:05:16 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:aJan 07 13:05:17 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:aJan 07 13:05:18 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:aJan 07 13:05:21 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:aJan 07 13:05:22 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:aJan 07 13:05:26 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:aJan 07 13:05:27 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:aJan 07 13:05:31 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:aJan 07 13:05:31 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:aJan 07 13:05:35 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:aJan 07 13:05:39 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:alines 2397-2445/2445 (END)
—
— Unit session-178.scope has finished starting up.
—
— The start-up result is done.
Jan 07 13:05:01 centos-79-64-minimal systemd[1]: Started Session 179 of user root.
— Subject: Unit session-179.scope has finished start-up
— Defined-By: systemd
— Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
—
— Unit session-179.scope has finished starting up.
—
— The start-up result is done.
Jan 07 13:05:01 centos-79-64-minimal systemd[1]: Started Session 180 of user bitrix.
— Subject: Unit session-180.scope has finished start-up
— Defined-By: systemd
— Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
—
— Unit session-180.scope has finished starting up.
—
— The start-up result is done.
Jan 07 13:05:01 centos-79-64-minimal CROND[11297]: (root) CMD (/opt/webdir/bin/restart_httpd-scale.sh process)
Jan 07 13:05:01 centos-79-64-minimal CROND[11298]: (root) CMD (/opt/webdir/bin/update_network.sh eno1)
Jan 07 13:05:01 centos-79-64-minimal CROND[11299]: (bitrix) CMD (test -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php && { /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php; } >/dev/null 2>&1)
Jan 07 13:05:01 centos-79-64-minimal CROND[11300]: (bitrix) CMD (/usr/bin/php -f /home/bitrix/www/bitrix/php_interface/cron_events.php)
Jan 07 13:05:01 centos-79-64-minimal systemd[1]: Removed slice User Slice of bitrix.
— Subject: Unit user-600.slice has finished shutting down
— Defined-By: systemd
— Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
—
— Unit user-600.slice has finished shutting down.
Jan 07 13:05:05 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:a7:92:08:00 SRC=92.63.197.5 DST=162.55.239.104 LEN=40 TOS=0x00 PREC=0x00 TTL=250 ID=36237 PROTO=TCP SPT=55875 DPT=21583 WINDOW=1024 RES=0x00 SYN URGP=0
Jan 07 13:05:07 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:a7:92:08:00 SRC=79.124.62.78 DST=162.55.239.104 LEN=40 TOS=0x00 PREC=0x00 TTL=248 ID=7191 PROTO=TCP SPT=58659 DPT=63767 WINDOW=1024 RES=0x00 SYN URGP=0
Jan 07 13:05:08 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:a7:92:08:00 SRC=92.63.197.5 DST=162.55.239.104 LEN=40 TOS=0x00 PREC=0x00 TTL=250 ID=35939 PROTO=TCP SPT=55875 DPT=48721 WINDOW=1024 RES=0x00 SYN URGP=0
Jan 07 13:05:09 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:a7:92:08:00 SRC=92.63.197.5 DST=162.55.239.104 LEN=40 TOS=0x00 PREC=0x00 TTL=250 ID=36237 PROTO=TCP SPT=55875 DPT=21583 WINDOW=1024 RES=0x00 SYN URGP=0
Jan 07 13:05:12 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:a7:92:08:00 SRC=92.63.196.61 DST=162.55.239.104 LEN=40 TOS=0x00 PREC=0x00 TTL=248 ID=31284 PROTO=TCP SPT=50389 DPT=3404 WINDOW=1024 RES=0x00 SYN URGP=0
Jan 07 13:05:13 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:a7:92:08:00 SRC=92.63.197.5 DST=162.55.239.104 LEN=40 TOS=0x00 PREC=0x00 TTL=250 ID=35939 PROTO=TCP SPT=55875 DPT=48721 WINDOW=1024 RES=0x00 SYN URGP=0
Jan 07 13:05:13 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:a7:92:08:00 SRC=45.143.203.12 DST=162.55.239.104 LEN=40 TOS=0x00 PREC=0x00 TTL=249 ID=10514 PROTO=TCP SPT=45923 DPT=44393 WINDOW=1024 RES=0x00 SYN URGP=0
Jan 07 13:05:13 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:a7:92:08:00 SRC=92.63.197.5 DST=162.55.239.104 LEN=40 TOS=0x00 PREC=0x00 TTL=250 ID=36237 PROTO=TCP SPT=55875 DPT=21583 WINDOW=1024 RES=0x00 SYN URGP=0
Jan 07 13:05:16 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:a7:92:08:00 SRC=92.63.197.86 DST=162.55.239.104 LEN=40 TOS=0x00 PREC=0x00 TTL=250 ID=64158 PROTO=TCP SPT=45993 DPT=48560 WINDOW=1024 RES=0x00 SYN URGP=0
Jan 07 13:05:17 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:a7:92:08:00 SRC=92.63.197.5 DST=162.55.239.104 LEN=40 TOS=0x00 PREC=0x00 TTL=250 ID=35939 PROTO=TCP SPT=55875 DPT=48721 WINDOW=1024 RES=0x00 SYN URGP=0
Jan 07 13:05:18 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:a7:92:08:00 SRC=92.63.197.5 DST=162.55.239.104 LEN=40 TOS=0x00 PREC=0x00 TTL=250 ID=55945 PROTO=TCP SPT=55875 DPT=33344 WINDOW=1024 RES=0x00 SYN URGP=0
Jan 07 13:05:21 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:a7:92:08:00 SRC=92.63.197.5 DST=162.55.239.104 LEN=40 TOS=0x00 PREC=0x00 TTL=250 ID=35939 PROTO=TCP SPT=55875 DPT=48721 WINDOW=1024 RES=0x00 SYN URGP=0
Jan 07 13:05:22 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:a7:92:08:00 SRC=92.63.197.5 DST=162.55.239.104 LEN=40 TOS=0x00 PREC=0x00 TTL=250 ID=55945 PROTO=TCP SPT=55875 DPT=33344 WINDOW=1024 RES=0x00 SYN URGP=0
Jan 07 13:05:26 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:a7:92:08:00 SRC=92.63.197.5 DST=162.55.239.104 LEN=40 TOS=0x00 PREC=0x00 TTL=250 ID=26020 PROTO=TCP SPT=55875 DPT=43080 WINDOW=1024 RES=0x00 SYN URGP=0
Jan 07 13:05:27 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:a7:92:08:00 SRC=92.63.197.5 DST=162.55.239.104 LEN=40 TOS=0x00 PREC=0x00 TTL=250 ID=55945 PROTO=TCP SPT=55875 DPT=33344 WINDOW=1024 RES=0x00 SYN URGP=0
Jan 07 13:05:31 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:a7:92:08:00 SRC=92.63.197.5 DST=162.55.239.104 LEN=40 TOS=0x00 PREC=0x00 TTL=250 ID=26020 PROTO=TCP SPT=55875 DPT=43080 WINDOW=1024 RES=0x00 SYN URGP=0
Jan 07 13:05:31 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:a7:92:08:00 SRC=92.63.197.5 DST=162.55.239.104 LEN=40 TOS=0x00 PREC=0x00 TTL=250 ID=55945 PROTO=TCP SPT=55875 DPT=33344 WINDOW=1024 RES=0x00 SYN URGP=0
Jan 07 13:05:35 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:a7:92:08:00 SRC=92.63.197.5 DST=162.55.239.104 LEN=40 TOS=0x00 PREC=0x00 TTL=250 ID=26020 PROTO=TCP SPT=55875 DPT=43080 WINDOW=1024 RES=0x00 SYN URGP=0
Jan 07 13:05:39 centos-79-64-minimal kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=24:4b:fe:b9:3e:2c:b4:8a:5f:36:a7:92:08:00 SRC=92.63.197.5 DST=162.55.239.104 LEN=40 TOS=0x00 PREC=0x00 TTL=250 ID=26020 PROTO=TCP SPT=55875 DPT=43080 WINDOW=1024 RES=0x00 SYN URGP=0
# nginx -t
nginx: [emerg] cannot load certificate «/etc/letsencrypt/live/some.copy2.site.ru/fullchain.pem»: BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen(‘/etc/letsencrypt/live/some.copy2.site.ru/fullchain.pem’,’r’) error:2006D080:BIO routines:BIO_new_file:no such file)
nginx: configuration file /etc/nginx/nginx.conf test failed
Попытки переименовать WWW в папке HOME и установить по новой не помогают.
Буду признателен за помощь!
When configuring your SSL certificates on Nginx, it’s not uncommon to see several errors when you try to reload your Nginx configuration, to activate the SSL Certificates.
This post describes the following type of errors:
- PEM_read_bio_X509: ASN1_CHECK_TLEN:wrong tag error
- PEM_read_bio_X509_AUX: Expecting: TRUSTED CERTIFICATE
- SSL_CTX_use_PrivateKey_file: bad base64 decode error
Read on for more details.
Nginx PEM_read_bio_X509: ASN1_CHECK_TLEN:wrong tag error
These kind of errors pop up when your certificate file isn’t valid. The entire error looks like this.
$ service nginx restart
nginx: [emerg] PEM_read_bio_X509("/etc/nginx/ssl/mydomain.tld/certificate.crt") failed (SSL: error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:Type=X509_CINF error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:Field=cert_info, Type=X509 error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1 lib)
You should fix this by beginning to read the SSL certificate info via the CLI. Chances are, OpenSSL will also show you an error, to confirm your SSL certificate isn’t valid.
In the example above, the SSL certificate is in /etc/nginx/ssl/mydomain.tld/certificate.crt, so the following examples continue to use that file.
$ openssl x509 -text -noout -in /etc/nginx/ssl/mydomain.tld/certificate.crt unable to load certificate 139894337988424:error:0906D064:PEM routines:PEM_read_bio:bad base64 decode:pem_lib.c:818:
If that’s your output, you have confirmation: your SSL certificate is corrupt. It’s got unsupported ASCII characters, it’s missing a part, some copy/paste error caused extra data to be present, … Bottom line: your certificate file won’t work.
You can test a few things yourself, like new line issues (linux vs. windows remains a problem). Open the file in binary mode in vi, and if you see ^M at end of every line, you’ve incorrectly got Windows new lines instead of Unix new lines.
$ vi -b /etc/nginx/ssl/mydomain.tld/certificate.crt -----BEGIN CERTIFICATE-----^M MIIFUjCCBDqgAwIBAgIKYsvzdQAAAAAAzTANBgkqhkiG9w0BAQUFADBOMQswCQYD^M ...
Remove all new lines and replace them with “normal” unix new lines (n instead of rn).
If your SSL certificate file contains multiple certificates, like intermediate or CA root certificates, it’s important to check each of them separately. You can check this by counting the «-—-BEGIN CERTIFICATE-—-« lines in the file.
If you’ve got multiple certificates, copy/paste each one to a different file and run the openssl example above. Each should give you valid output from the SSL certificate.
$ grep 'BEGIN CERTIFICATE' /etc/nginx/ssl/mydomain.tld/certificate.crt -----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
The output above shows that the SSL Certificate file contains 3 individual SSL certificates. Copy/paste them all in separate files and validate if they work. If one of them gives you errors, fix that one: find the wrong ASCII characters, fix the new lines, check if you copy/pasted it correctly from your vendor, …
The “nginx: [emerg] PEM_read_bio_X509” error means your Nginx configuration is probably correct, it’s the SSL certificate file itself that is invalid.
Nginx PEM_read_bio_X509_AUX: Expecting: TRUSTED CERTIFICATE
This is an error that is usually resolved very quickly. The certificate file you’re pointing your config to, isn’t a certificate file. At least, not according to Nginx.
$ service nginx configtest
nginx: [emerg] PEM_read_bio_X509_AUX("/etc/nginx/ssl/mydomain.tld/certificate.crt") failed (SSL: error:0906D06C:PEM routines:PEM_read_bio:no start line:Expecting: TRUSTED CERTIFICATE)
nginx: configuration file /etc/nginx/nginx.conf test failed
This can happen if you’ve accidentally swapped your private key and SSL certificate in either your files, or in the Nginx configuration.
Your Nginx config will contain these kind of lines for its SSL configuration.
ssl_certificate /etc/nginx/ssl/mydomain.tld/certificate.crt; ssl_certificate_key /etc/nginx/ssl/mydomain.tld/certificate.key;
Check if the ssl_certificate file is indeed your SSL certificate and if the ssl_certificate_key is indeed your key. It’s not uncommon to mix these up if you’re in a hurry or distracted and save the wrong contents to the wrong file.
Nginx SSL_CTX_use_PrivateKey_file: bad base64 decode error
Another common error in Nginx configurations is the following one.
$ service nginx configtest
nginx: [emerg] SSL_CTX_use_PrivateKey_file("/etc/nginx/ssl/mydomain.tld/certificate.key") failed (SSL: error:0906D064:PEM routines:PEM_read_bio:bad base64 decode error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib)
nginx: configuration file /etc/nginx/nginx.conf test failed
Note how the Nginx SSL error points to the .key file this time. The problem is with the SSL key, not the SSL certificate.
This error indicates that the private key you pointed your configuration to, doesn’t match the SSL Certificate.
You can validate whether private key and SSL certificate match by calculating their MD5 hash. If they don’t match, you have to find either the right certificate or the right private key file.
One of them is wrong and needs to be replaced. With this error, it’s impossible to know which one is wrong. Your best bet is to read the info from the SSL certificate, determine if that’s the correct SSL certificate (check expiration date, SANs, Common Name, …), and find the matching key (which should have been created when you generated your Certificate Signing Request, CSR).
Hi, I was able to connect to ws, but no luck with wss.
Can you check what’s wrong? I’m using v3-stable branch.
Attached full source and logs.
int main()
{
lws_set_log_level(31, NULL); // We don't need to see the notice messages
signal(SIGINT, onSigInt); // Register the SIGINT handler
// Connection info
char inputURL[300] = "wss://echo.websocket.org";
int inputPort = 9000;
struct lws_context_creation_info ctxCreationInfo; // Context creation info
struct lws_client_connect_info clientConnectInfo; // Client creation info
struct lws_context *ctx; // The context to use
struct lws *wsiTest; // WebSocket interface
const char *urlProtocol, *urlTempPath; // the protocol of the URL, and a temporary pointer to the path
char urlPath[300]; // The final path string
// Set both information to empty and allocate it's memory
memset(&ctxCreationInfo, 0, sizeof(ctxCreationInfo));
memset(&clientConnectInfo, 0, sizeof(clientConnectInfo));
clientConnectInfo.port = inputPort; // Set the client info's port to the input port
// Parse the input url (e.g. wss://echo.websocket.org:1234/test)
// the protocol (wss)
// the address (echo.websocket.org)
// the port (1234)
// the path (/test)
if (lws_parse_uri(inputURL, &urlProtocol, &clientConnectInfo.address, &clientConnectInfo.port, &urlTempPath))
{
printf("Couldn't parse URLn");
}
// Fix up the urlPath by adding a / at the beginning, copy the temp path, and add a at the end
urlPath[0] = '/';
strncpy(urlPath + 1, urlTempPath, sizeof(urlPath) - 2);
urlPath[sizeof(urlPath) - 1] = '';
// urlPath[0] = '';
clientConnectInfo.path = urlPath; // Set the info's path to the fixed up url path
// Set up the context creation info
ctxCreationInfo.port = CONTEXT_PORT_NO_LISTEN; // We don't want this client to listen
ctxCreationInfo.protocols = protocols; // Use our protocol list
ctxCreationInfo.gid = -1; // Set the gid and uid to -1, isn't used much
ctxCreationInfo.uid = -1;
ctxCreationInfo.extensions = extensions; // Use our extensions list
// Create the context with the info
printf("%dn", ctxCreationInfo.options);
ctxCreationInfo.options = LWS_SERVER_OPTION_DO_SSL_GLOBAL_INIT;
ctx = lws_create_context(&ctxCreationInfo);
if (ctx == NULL)
{
printf("Error creating contextn");
return 1;
}
// LCCSCF_USE_SSL = (1 << 0),
// LCCSCF_ALLOW_SELFSIGNED = (1 << 1),
// LCCSCF_SKIP_SERVER_CERT_HOSTNAME_CHECK = (1 << 2),
// LCCSCF_ALLOW_EXPIRED = (1 << 3),
// LCCSCF_PIPELINE = (1 << 16),
// Set up the client creation info
clientConnectInfo.context = ctx; // Use our created context
clientConnectInfo.ssl_connection = LCCSCF_USE_SSL | LCCSCF_ALLOW_SELFSIGNED | LCCSCF_SKIP_SERVER_CERT_HOSTNAME_CHECK; // Don't use SSL for this test
clientConnectInfo.host = clientConnectInfo.address; // Set the connections host to the address
clientConnectInfo.origin = clientConnectInfo.address; // Set the conntections origin to the address
clientConnectInfo.ietf_version_or_minus_one = -1; // IETF version is -1 (the latest one)
clientConnectInfo.protocol = protocols[PROTOCOL_TEST].name; // We use our test protocol
clientConnectInfo.pwsi = &wsiTest; // The created client should be fed inside the wsi_test variable
printf("Connecting to %s://%s:%d%s nn", urlProtocol, clientConnectInfo.address, clientConnectInfo.port, urlPath);
// Connect with the client info
lws_client_connect_via_info(&clientConnectInfo);
if (wsiTest == NULL)
{
printf("Error creating the clientn");
return 1;
}
// Main loop runs till bExit is true, which forces an exit of this loop
while (!bExit)
{
// LWS' function to run the message loop, which polls in this example every 50 milliseconds on our created context
lws_service(ctx, 50);
}
// Destroy the context
lws_context_destroy(ctx);
printf("nDone executing.n");
return 0;
}
kendo@kendo-virtual-machine:~/pjproject-2.6/libwebsockets/build$ ./bin/libwebsockets-test-client
0
[2018/09/22 04:56:12:1777] INFO: Initial logging level 31
[2018/09/22 04:56:12:1777] INFO: Libwebsockets version: 3.0.99 v3.0.0-138-g64ea98f
[2018/09/22 04:56:12:1777] INFO: IPV6 not compiled in
[2018/09/22 04:56:12:1777] INFO: LWS_DEF_HEADER_LEN : 4096
[2018/09/22 04:56:12:1777] INFO: LWS_MAX_PROTOCOLS : 5
[2018/09/22 04:56:12:1777] INFO: LWS_MAX_SMP : 1
[2018/09/22 04:56:12:1777] INFO: sizeof (*info) : 496
[2018/09/22 04:56:12:1777] INFO: SYSTEM_RANDOM_FILEPATH: '/dev/urandom'
[2018/09/22 04:56:12:1777] INFO: HTTP2 support : not configured
[2018/09/22 04:56:12:1777] DEBUG: _realloc: size 776: context
[2018/09/22 04:56:12:1777] INFO: Using event loop: poll
[2018/09/22 04:56:12:1777] INFO: Default ALPN advertisment: http/1.1
[2018/09/22 04:56:12:1777] INFO: default timeout (secs): 20
[2018/09/22 04:56:12:1777] DEBUG: _realloc: size 4096: pt_serv_buf
[2018/09/22 04:56:12:1777] INFO: Threads: 1 each 1024 fds
[2018/09/22 04:56:12:1777] INFO: mem: context: 4872 B (776 ctx + (1 thr x 4096))
[2018/09/22 04:56:12:1777] INFO: mem: http hdr rsvd: 5177344 B (1 thr x (4096 + 960) x 1024))
[2018/09/22 04:56:12:1778] DEBUG: _realloc: size 8192: fds table
[2018/09/22 04:56:12:1778] INFO: mem: pollfd map: 8192
[2018/09/22 04:56:12:1778] DEBUG: _realloc: size 8192: lws_lookup
[2018/09/22 04:56:12:1778] INFO: mem: platform fd map: 8192 bytes
[2018/09/22 04:56:12:1778] DEBUG: _realloc: size 472: event pipe wsi
[2018/09/22 04:56:12:1778] DEBUG: lws_role_transition: 0x11147d0: wsistate 0x200, ops pipe
[2018/09/22 04:56:12:1778] DEBUG: event pipe fd 5
[2018/09/22 04:56:12:1778] DEBUG: __insert_wsi_socket_into_fds: 0x11147d0: tsi=0, sock=5, pos-in-fds=0
[2018/09/22 04:56:12:1778] INFO: Compiled with OpenSSL support
[2018/09/22 04:56:12:1778] INFO: Doing SSL library init
[2018/09/22 04:56:12:1789] DEBUG: _realloc: size 648: create vhost
[2018/09/22 04:56:12:1789] DEBUG: _realloc: size 112: vhost-specific plugin table
[2018/09/22 04:56:12:1789] DEBUG: _realloc: size 8: same vh list
[2018/09/22 04:56:12:1789] NOTICE: Creating Vhost 'default' (serving disabled), 1 protocols, IPv6 off
[2018/09/22 04:56:12:1791] NOTICE: created client ssl context for default
[2018/09/22 04:56:12:1791] INFO: mem: per-conn: 472 bytes + protocol rx buf
[2018/09/22 04:56:12:1791] INFO: canonical_hostname = kendo-virtual-machine
[2018/09/22 04:56:12:1791] INFO: lws_cancel_service
Connecting to wss://echo.websocket.org:443//
[2018/09/22 04:56:12:1792] INFO: lws_protocol_init
[2018/09/22 04:56:12:1792] DEBUG: _realloc: size 472: client wsi
[2018/09/22 04:56:12:1792] INFO: lws_vhost_bind_wsi: vh default: count_bound_wsi 1
[2018/09/22 04:56:12:1792] DEBUG: _realloc: size 200: client ws struct
[2018/09/22 04:56:12:1792] DEBUG: lws_role_transition: 0x1139350: wsistate 0x10000200, ops h1
[2018/09/22 04:56:12:1792] INFO: lws_client_connect_via_info: protocol binding to test-protocol
[2018/09/22 04:56:12:1792] INFO: lws_same_vh_protocol_remove: removing same prot wsi 0x1139350
[2018/09/22 04:56:12:1792] DEBUG: lws_ensure_user_space: 0x1139350 protocol pss 0, user_space=(nil)
[Test Protocol] Connection client closed.
[2018/09/22 04:56:12:1792] DEBUG: _realloc: size 64: client stash
[2018/09/22 04:56:12:1792] DEBUG: _realloc: size 19: strdup
[2018/09/22 04:56:12:1792] DEBUG: _realloc: size 3: strdup
[2018/09/22 04:56:12:1792] DEBUG: _realloc: size 19: strdup
[2018/09/22 04:56:12:1793] DEBUG: _realloc: size 19: strdup
[2018/09/22 04:56:12:1793] DEBUG: _realloc: size 14: strdup
[2018/09/22 04:56:12:1793] DEBUG: _realloc: size 9: strdup
[2018/09/22 04:56:12:1793] INFO: lws_header_table_attach: wsi 0x1139350: ah (nil) (tsi 0, count = 0) in
[2018/09/22 04:56:12:1793] DEBUG: _realloc: size 960: ah struct
[2018/09/22 04:56:12:1793] DEBUG: _realloc: size 4096: ah data
[2018/09/22 04:56:12:1793] INFO: _lws_create_ah: created ah 0x1139710 (size 4096): pool length 1
[2018/09/22 04:56:12:1793] INFO: lws_header_table_attach: did attach wsi 0x1139350: ah 0x1139710: count 1 (on exit)
[2018/09/22 04:56:12:1793] DEBUG: __lws_set_timeout: 0x1139350: 10 secs (reason 25)
[2018/09/22 04:56:12:1793] DEBUG: _realloc: size 19: strdup
[2018/09/22 04:56:12:1793] INFO: lws_client_connect_2: 0x1139350: address echo.websocket.org
[2018/09/22 04:56:12:3132] DEBUG: lwsi_set_state(0x1139350, 0x10000201)
[2018/09/22 04:56:12:3132] DEBUG: __insert_wsi_socket_into_fds: 0x1139350: tsi=0, sock=17, pos-in-fds=1
[2018/09/22 04:56:12:3132] DEBUG: _lws_change_pollfd: wsi 0x1139350: fd 17 events 1 -> 1
[2018/09/22 04:56:12:3132] DEBUG: __lws_set_timeout: 0x1139350: 20 secs (reason 2)
[2018/09/22 04:56:12:3133] DEBUG: _lws_change_pollfd: wsi 0x1139350: fd 17 events 1 -> 5
[2018/09/22 04:56:12:5441] DEBUG: _lws_change_pollfd: wsi 0x1139350: fd 17 events 5 -> 1
[2018/09/22 04:56:12:5441] INFO: lws_client_connect_2: 0x1139350: address echo.websocket.org
[2018/09/22 04:56:12:6521] INFO: lws_client_connect_2: wsi 0x1139350: client creating own connection
[2018/09/22 04:56:12:6521] DEBUG: lwsi_set_state(0x1139350, 0x10000011)
[2018/09/22 04:56:12:6521] DEBUG: __lws_set_timeout: 0x1139350: 20 secs (reason 8)
[2018/09/22 04:56:12:6521] DEBUG: _lws_change_pollfd: wsi 0x1139350: fd 17 events 1 -> 1
[2018/09/22 04:56:12:6521] INFO: client conn using alpn list 'http/1.1'
[2018/09/22 04:56:12:6523] DEBUG: lws_ssl_get_error: 0x113d0f0 -1 -> 2 (errno 11)
[2018/09/22 04:56:12:6523] DEBUG: lwsi_set_state(0x1139350, 0x10000203)
[2018/09/22 04:56:12:8860] DEBUG: lws_ssl_get_error: 0x113d0f0 -1 -> 2 (errno 11)
[2018/09/22 04:56:12:8861] DEBUG: lws_ssl_client_connect2: SSL_connect says -2
[2018/09/22 04:56:12:8861] DEBUG: lwsi_set_state(0x1139350, 0x10000203)
[2018/09/22 04:56:12:8865] NOTICE: accepting self-signed certificate (verify_callback)
[2018/09/22 04:56:12:8869] DEBUG: lws_ssl_get_error: 0x113d0f0 -1 -> 2 (errno 11)
[2018/09/22 04:56:12:8869] DEBUG: lws_ssl_client_connect2: SSL_connect says -2
[2018/09/22 04:56:12:8869] DEBUG: lwsi_set_state(0x1139350, 0x10000203)
[2018/09/22 04:56:13:1245] INFO: lws_role_call_alpn_negotiated: ''
[2018/09/22 04:56:13:1245] INFO: client connect OK
[2018/09/22 04:56:13:1245] DEBUG: lws_ssl_client_connect2: SSL_connect says 0
[2018/09/22 04:56:13:1245] DEBUG: get_verify says 0
[2018/09/22 04:56:13:1245] DEBUG: lwsi_set_state(0x1139350, 0x10000012)
[2018/09/22 04:56:13:1245] DEBUG: __lws_set_timeout: 0x1139350: 20 secs (reason 11)
[2018/09/22 04:56:13:1245] INFO: lws_client_socket_service: HANDSHAKE2: 0x1139350: sending headers on 0x1139350 (wsistate 0x10000012 0x10000012)
[2018/09/22 04:56:13:1246] DEBUG: lwsi_set_state(0x1139350, 0x1000020a)
[2018/09/22 04:56:13:1246] DEBUG: __lws_set_timeout: 0x1139350: 20 secs (reason 4)
[2018/09/22 04:56:13:1246] DEBUG: _lws_change_pollfd: wsi 0x1139350: fd 17 events 1 -> 5
[2018/09/22 04:56:13:1246] DEBUG: lwsi_set_state(0x1139350, 0x1000020a)
[2018/09/22 04:56:13:1246] DEBUG: __lws_set_timeout: 0x1139350: 20 secs (reason 4)
[2018/09/22 04:56:13:1246] DEBUG: _lws_change_pollfd: wsi 0x1139350: fd 17 events 5 -> 1
[2018/09/22 04:56:13:3566] DEBUG: 0x1139350: SSL_read says 1
[2018/09/22 04:56:13:3567] DEBUG: 0x1139350: SSL_read says 1
...
[2018/09/22 04:56:13:3651] DEBUG: 0x1139350: SSL_read says 1
[2018/09/22 04:56:13:3651] DEBUG: 0x1139350: SSL_read says 1
[2018/09/22 04:56:13:3651] INFO: lws_client_ws_upgrade: WSI_TOKEN_PROTOCOL is null
[2018/09/22 04:56:13:3651] DEBUG: lws_ensure_user_space: 0x1139350 protocol pss 0, user_space=(nil)
[2018/09/22 04:56:13:3651] DEBUG: __lws_set_timeout: 0x1139350: 0 secs (reason 0)
[2018/09/22 04:56:13:3651] INFO: __lws_header_table_detach: wsi 0x1139350: ah 0x1139710 (tsi=0, count = 1)
[2018/09/22 04:56:13:3651] INFO: __lws_header_table_detach: nobody usable waiting
[2018/09/22 04:56:13:3797] INFO: _lws_destroy_ah: freed ah 0x1139710 : pool length 0
[2018/09/22 04:56:13:3797] INFO: __lws_header_table_detach: wsi 0x1139350: ah 0x1139710 (tsi=0, count = 0)
[2018/09/22 04:56:13:3797] DEBUG: lws_role_transition: 0x1139350: wsistate 0x10000117, ops ws
[2018/09/22 04:56:13:3797] DEBUG: _realloc: size 532: client frame buffer
[2018/09/22 04:56:13:3797] INFO: Allocating client RX buffer 528
[2018/09/22 04:56:13:3797] DEBUG: handshake OK for protocol test-protocol
[Test Protocol] Connection to server established.
[Test Protocol] Writing "Simple webserver echo test!" to server.
[2018/09/22 04:56:13:3799] DEBUG: 0x1139350: SSL_read says 0
[2018/09/22 04:56:13:3799] DEBUG: lws_ssl_get_error: 0x113d0f0 0 -> 6 (errno 0) <----error here
[2018/09/22 04:56:13:3799] NOTICE: 0x1139350: ssl err 6 errno 0 <----error here
[2018/09/22 04:56:13:3799] INFO: rops_handle_POLLIN_ws: LWS_SSL_CAPABLE_ERROR
[2018/09/22 04:56:13:3799] DEBUG: 0x1139350: Close and handled
[2018/09/22 04:56:13:3799] INFO: __lws_close_free_wsi: 0x1139350: caller: close_and_handled
[2018/09/22 04:56:13:3799] DEBUG: __lws_close_free_wsi: real just_kill_connection: 0x1139350 (sockfd 17)
[2018/09/22 04:56:13:3799] INFO: lws_same_vh_protocol_remove: removing same prot wsi 0x1139350
[2018/09/22 04:56:13:3799] INFO: have prev 0x1139418, setting him to our next 0x1139350
[2018/09/22 04:56:13:3799] DEBUG: __remove_wsi_socket_from_fds: wsi=0x1139350, sock=17, fds pos=1, end guy pos=2, endfd=0
[2018/09/22 04:56:13:3799] DEBUG: lwsi_set_state(0x1139350, 0x1000001e)
Let’s Encrypt is a free and open-source Certificate Authority managed by the Internet Security Research Group. It uses Automated Certificate Management Environment (ACME) server to validate the domain and deploy free SSL certificates automatically that are trusted by all major browsers. The main goal of this project to make encrypted connections throughout the Internet.
Let’s Encrypt provides an easy way to install and deploy SSL certificate for your website for free using a command-line tool called Certbot and is fully supported by Webdock natively in our control panel
Let’s Encrypt Certbot sometimes kicks up a fuss however for a variety of reasons. In this article we document the most commonly encountered errors we see on our platform and how to solve them.
Regardless of the specific error you are encountering, in 99% of all cases the following operations in Webdock clear things up nicely:
If you are still seeing issues — especially timeout/connection issues on older Ubuntu systems — please try the following as well:
If despite all these common steps which usually resolve Certbot issues you are still having problems — please find your error below and follow our suggestions in order to resolve that specific problem.
Make sure your Certbot installation is up to date
As of late 2020 Certbot is no longer maintained as an apt package and you should make sure it is running through Snap on Ubuntu. This procedure is totally safe and easy to do.
Please read our full article on this topic in order to get up to speed.
Checking if your Let’s Encrypt Certificate is working
Typically Certbot runs fine in Webdock the first time you run it and problems crop up over time or when you do changes to your configuration. Often the first indication you get of a problem is when you get an email from Let’s Encrypt with a title similar to «Let’s Encrypt certificate expiration notice for domain xxx»
When you generate certificates with Webdock we automatically add a Cron job which keeps your certificate up to date. If you get this email then this means your certificate may be about to expire and you need to check if renewals are working.
In Webdock you can simply run the «Test Certbot renewal» script on your server on the Server Scripts page.
What this script essentially does is runs the following command on your server and returns the output so you can inspect what is happening
certbot renew --dry-run
In the following sections we detail various error messages which may show up here and what to do about them.
Invalid response / The client lacks sufficient authorization
If you get a message similar to the following
Saving debug log to /var/log/letsencrypt/letsencrypt.log Obtaining a new certificate Performing the following challenges: http-01 challenge for mydomain.com http-01 challenge for www.mydomain.com Using the webroot path /var/www/html for all unmatched domains. Waiting for verification... Cleaning up challenges Failed authorization procedure. mydomain.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://mydomain.com/.well-known/acme-challenge/pYpAC6kT25C0itcTNKd8hwb_0VaoPxJVIkVg5_xn-N4 [77.111.240.95]: 403 IMPORTANT NOTES: - The following errors were reported by the server: Domain: mydomain.com Type: unauthorized Detail: Invalid response from http://mydomain.com/.well-known/acme-challenge/pYpAC6kT25C0itcTNKd8hwb_0VaoPxJVIkVg5_xn-N4 [77.111.240.95]: 403 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.
Try the suggested fix: Check if your DNS records are OK
First thing to check are your DNS records and whether your A and AAAA records are OK and pointing to your server. However, if your certificate has worked before and you reach your website just fine, then it is unlikely this is the culprit.
However, you should keep an eye on whether there are any web forwards configured (some DNS providers allow this) e.g. if you forward www to non-www or vice-versa, this may trip up Certbot. In which case remove the domain you are forwarding using DNS from your certificate. This should resolve the issue.
To remove a domain in Webdock you simply run Server Identity with the domains you want your webserver to actually respond to and then run the SSL Certificates tool once more.
On Apache: Make sure you exclude Certbot from any .htaccess rewrites
If you are on Apache, check if you have a .htaccess file with rewrites in your web root. If you have such a file you should place a rule to exclude Let’s Encrypt Certbot from any rewrites by placing the exception before any RewriteCond statements. For example:
RewriteEngine on
RewriteRule ^.well-known/acme-challenge/ - [L]
RewriteCond %{SERVER_NAME} =mydomain.demo.com [OR]
RewriteCond %{SERVER_NAME} =www.mydomain.com [OR]
RewriteCond %{SERVER_NAME} =livesite.mydomain.com [OR]
RewriteCond %{SERVER_NAME} =mydomain.com [OR]
RewriteCond %{SERVER_NAME} =mydomain.dk [OR]
RewriteCond %{SERVER_NAME} =www.mydomain.dk
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
Once you’ve placed the acme-challenge RewriteRule in there, try running Certbot again.
On Apache: Try rolling back completely and nuking any Certbot config
If your DNS records and rewrites are ok and Certbot renew still fails, you should try and issue the certbot rollback command:
certbot rollback
If this gives you errors, try removing the Let’s Encrypt SSL configuration file located at (in default Webdock stacks):
/etc/apache2/sites-enabled/webdock-le-ssl.conf
Next run Certbot rollback — and if it succeeds keep running it untill it says it hasn’t touched your configuration. You should now be back to a stock configuration and you should be able to run the SSL Certificates tool once more to generate a new certificate.
If you are not using Webdock and following this guide, you should make sure you back up your configuration before doing this and make sure your config is as you want it and working for vanilla http before running Certbot.
On Nginx: Make sure you exclude Certbot from any deny rules
Similar to Apache, if you have custom configuration which excludes access to hidden directories, such as the following:
# Deny all attempts to access hidden files such as .htaccess, .htpasswd, .DS_Store (Mac).
# Keep logging the requests to parse later (or to pass to firewall utilities such as fail2ban)
location ~ /. {
deny all;
}
You need to add the following rule beofre this in order to allow Certbot to validate using the web root method:
# Necessary for Let's Encrypt Domain Name ownership validation
location ~ /.well-known {
allow all;
}
Error while running apache2ctl configtest
This error is related to the last fix detailed above and can be solved in the same manner, if you encounter a message like the following:
Error while running apache2ctl configtest. Action 'configtest' failed. The Apache error log may have more information. AH00526: Syntax error on line 30 of /etc/apache2/sites-enabled/000-default-le-ssl.conf: SSLCertificateFile: file '/etc/letsencrypt/live/mydomain.com/fullchain.pem' does not exist or is empty
Simply delete the old config and try again
During the Webdock Let’s Encrypt SSL installation, a Certbot rollback command hasn’t completely cleared an old default config file. You can resolve this by removing the file /etc/apache2/sites-enabled/000-default-le-ssl.conf and run Certbot once more.
No such file or directory error from Nginx
Sometimes during a Certbot rollback operation or when Certbot tries to renew/install a certificate, Nginx cannot start the webserver as there is till old Certbot configuration hanging around in your Nginx vhost config file. You may see an error like the following:
Error while running nginx -c /etc/nginx/nginx.conf -t.
nginx: [emerg] BIO_new_file("/etc/letsencrypt/live/mydomain.com-0001/fullchain.pem") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/letsencrypt/live/mydomain.com-0001/fullchain.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)
nginx: configuration file /etc/nginx/nginx.conf test failed
To solve this issue, remove any references to SSL certificates from your Nginx configuration file. The lines typically look like this:
listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/mydomain.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/mydomain.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
Once you have removed these lines run Certbot rollback untill it says nothing was modified. If you are using Webdock you would then run the Server Identity tool and finally the SSL Certificates tool and you will now have a shiny new (and working) certificate installed on your server.
If you are not using Webdock, you would likely issue another certbot rollback command and see if it succeeds, next review your config and make sure it is as you want it and that it works for vanilla http, finally you would run Certbot again to generate your certifcate.
Timeout Errors
If you get an error similar to the following:
IMPORTANT NOTES: - The following errors were reported by the server: Domain: mydomain.com Type: connection Detail: Fetching https://mydomain.com/.well-known/acme-challenge/m5JIZwyOioenm7XraPru2FV-8VPtCXF1YpoHmctfVDc: Timeout during connect (likely firewall problem)
You need to check whether your DNS records are OK and whether your webserver is listening on your server on port 80 and 443. Make sure you check whether you can ping and ping6 your domain. Typically we see this error happening is if AAAA records for a domain have not been updated, or there are old records pointing to a wrong IP hanging around — but a timeout might also indicate a networking issue (for example a firewall) as stated in the message, or that your server is actively refusing connections for some reason.
Another cause for this issue is that Nginx and Certbot are not aligned as to where your web root is located and Certbot is placing its verification files for web root authentication in the wrong place. A quick way to fix this in Webdock is to simply set the Web Root once more (the small pencil icon next to the web root in the Webdock dashboard) and then run renewal again.
The error may also look something like this:
Waiting for verification... Cleaning up challenges Attempting to renew cert (mydomain.com) from /etc/letsencrypt/renewal/mydomain.com.conf produced an unexpected error: HTTPSConnectionPool(host='acme-staging-v02.api.letsencrypt.org', port=443): Read timed out. (read timeout=45). Skipping. All renewal attempts failed. The following certs could not be renewed: /etc/letsencrypt/live/mydomain.com/fullchain.pem (failure)
In our experience, this specific message is due to Let’s Encrypt not being able to connect via. IPv6 — so check that IPv6 works if you have AAAA records for your domain, otherwise all the advice above is also applicable, i.e. check your DNS and connection issues in general. On some older Ubuntu systems (Xenial especially) a general package upgrade with apt update and apt upgrade has been seen by us as an easy resolution to some ipv6 connection issues.
Connection Refused Error
If you get a Connection Refused error when doing renewals, this may be due to old-style Certbot configuration not having written the appropriate configuration to your Nginx config in order to allow Nginx to listen on your IPv6 address. You would typically see an error like the following:
IMPORTANT NOTES: - The following errors were reported by the server: Domain: mydomain.com Type: connection Detail: Fetching https://mydomain.com/.well-known/acme-challenge/ewpBCX7N0nzDyBZZILYP-y9sKHI4seFGac4Se7TpwfA: Connection refused
What this error really is saying is: Certbot could not connect to your domain on port 443. Typically what we see is that if you now check what is listening on which ports by running netstat you will get something like the following:
root@myserver:~# netstat -tapn Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:27017 0.0.0.0:* LISTEN 441/mongod tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 772/mysqld tcp 0 0 127.0.0.1:11211 0.0.0.0:* LISTEN 440/memcached tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 716522/nginx -g dae tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 614876/pure-ftpd (S tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 449/sshd tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 716522/nginx -g dae tcp6 0 0 :::80 :::* LISTEN 716522/nginx -g dae tcp6 0 0 :::21 :::* LISTEN 614876/pure-ftpd (S tcp6 0 0 :::22 :::* LISTEN 449/sshd
Notice how nginx is listening on tcp (ipv4) port 443 but not tcp6 (ipv6) ? This is the problem as the Let’s Encrypt certificate servers prefer to connect through ipv6 if there are AAAA records set up for your domain.
In order to solve this, check that you have the following line in your Nginx config (on Webdock servers the vhostconfig file is typically found at /etc/nginx/sites-enabled/webdock) , and if not, add it:
listen [::]:443 ssl ipv6only=on; # managed by Certbot
Next, restart Nginx:
systemctl restart nginx
Check that nginx is listening on tcp6 port 443 and try your renewal again. It should work this time — but if not, then make sure nginx is listening on the appropriate interfaces and on both ports 80 and 443 and is reachable from the outside, because if it is not you will get this error message.
Account creation on ACMEv1 is disabled
If you get an error message similar to the following
Certbot failed in schonherr Certbot message: Saving debug log to /var/log/letsencrypt/letsencrypt.log An unexpected error occurred: The client lacks sufficient authorization :: Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555. See https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 for details. Please see the logfiles in /var/log/letsencrypt for more details.
This simply means that the installed version of Certbot is too old and doesn’t support newer authentication methods. Simply upgrade your system with:
apt-get update -y apt-get upgrade -y
If it prompts you what to do about existing config files just choose the defaults which is to keep the existing configuration. Once the system is upgraded it is a good idea to reboot the system, or at the very least your webserver and php-fpm before trying again.
Please note: During the system upgrade your webserver will likely go down temporarily. Plan accordingly.
The request message was malformed
Similarily an indication your Certbot is too old may be seen from the following Certbot output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Processing /etc/letsencrypt/renewal/mydomain.com.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Cert not due for renewal, but simulating renewal for dry run Plugins selected: Authenticator webroot, Installer apache Renewing an existing certificate Attempting to renew cert (mydomain.com) from /etc/letsencrypt/renewal/mydomain.com.conf produced an unexpected error: urn:ietf:params:acme:error:malformed :: The request message was malformed :: Method not allowed. Skipping. All renewal attempts failed. The following certs could not be renewed: /etc/letsencrypt/live/mydomain.com/fullchain.pem (failure) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ** DRY RUN: simulating certbot renew close to cert expiry ** (The test certificates below have not been saved.) All renewal attempts failed. The following certs could not be renewed: /etc/letsencrypt/live/mydomain.com/fullchain.pem (failure) ** DRY RUN: simulating certbot renew close to cert expiry ** (The test certificates above have not been saved.) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1 renew failure(s), 0 parse failure(s)
The solution here is, as with the error above, to upgrade your system. The same warning applies: upgrading may bring down your webserver temporarily.
Test Certbot Renewal script hangs for a long time, prompts for a new webroot in output
Sometimes Webdock users experience that the Test Certbot renewal scripts hangs for a long time and then outputs something similar to the following:
Saving debug log to /var/log/letsencrypt/letsencrypt.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Processing /etc/letsencrypt/renewal/mydomain.com.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Cert is due for renewal, auto-renewing... Non-interactive renewal: random delay of 362 seconds Plugins selected: Authenticator webroot, Installer nginx Renewing an existing certificate Performing the following challenges: http-01 challenge for mydomain.com Cleaning up challenges Attempting to renew cert (mydomain.com) from /etc/letsencrypt/renewal/mydomain.com.conf produced an unexpected error: Missing command line flag or config entry for this setting: Select the webroot for mydomain.com: Choices: [Enter a new webroot, /var/www/html] (You can set this with the --webroot-path flag). Skipping. All renewal attempts failed. The following certs could not be renewed: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ** DRY RUN: simulating certbot renew close to cert expiry ** (The test certificates below have not been saved.) All renewal attempts failed. The following certs could not be renewed: /etc/letsencrypt/live/mydomain.com/fullchain.pem (failure) ** DRY RUN: simulating certbot renew close to cert expiry ** (The test certificates above have not been saved.) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - /etc/letsencrypt/live/mydomain.com/fullchain.pem (failure) 1 renew failure(s), 0 parse failure(s)
This is due to Certbot having «forgotten» what the appropriate web root is for your domain. We use web root authentication in order to avoid certain other issues with Cloudflare and Cloudflare caching. In any case, the solution here is to set the web root once more on your server, after which you should run the SSL Certificates tool once more. If you still get errors, try running the Server Identity tool first.