[GH-ISSUE #250] Unable to Generate SSL Certs (Let's Encrypt) #218

Closed
opened 2026-02-26 06:31:34 +03:00 by kerem · 9 comments
Owner

Originally created by @HNGamingUK on GitHub (Dec 3, 2019).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/250

Hello,

So when I go to create a new SSL Certificate within the "SSL Certificates" tab or via Proxy Hosts, it loads for sometime and then just provides "Internal Error"

Looking in /var/log/letsencrypt.log I found the following at the bottom:

2019-12-03 01:05:58,272:DEBUG:certbot.storage:Archive directory /etc/letsencrypt/archive/npm-6 and live directory /etc/letsencrypt/live/npm-6 created. 2019-12-03 01:05:58,274:DEBUG:certbot.log:Exiting abnormally: Traceback (most recent call last): File "/usr/bin/certbot", line 11, in <module> load_entry_point('certbot==0.28.0', 'console_scripts', 'certbot')() File "/usr/lib/python3/dist-packages/certbot/main.py", line 1340, in main return config.func(config, plugins) File "/usr/lib/python3/dist-packages/certbot/main.py", line 1225, in certonly lineage = _get_and_save_cert(le_client, config, domains, certname, lineage) File "/usr/lib/python3/dist-packages/certbot/main.py", line 121, in _get_and_save_cert lineage = le_client.obtain_and_enroll_certificate(domains, certname) File "/usr/lib/python3/dist-packages/certbot/client.py", line 410, in obtain_and_enroll_certificate self.config) File "/usr/lib/python3/dist-packages/certbot/storage.py", line 1053, in new_lineage target[kind]) OSError: [Errno 95] Operation not supported: '../../archive/npm-6/cert1.pem' -> '/etc/letsencrypt/live/npm-6/cert.pem' 2019-12-03 01:05:58,278:ERROR:certbot.log:An unexpected error occurred: 2019-12-03 01:05:59,238:DEBUG:certbot.util:Exception occurred releasing lock: LockFile(/var/log/letsencrypt/.certbot.lock) <released> Traceback (most recent call last): File "/usr/lib/python3/dist-packages/certbot/util.py", line 141, in _release_locks dir_lock.release() File "/usr/lib/python3/dist-packages/certbot/lock.py", line 122, in release compat.release_locked_file(self._fd, self._path) File "/usr/lib/python3/dist-packages/certbot/compat.py", line 154, in release_locked_file os.remove(path) OSError: [Errno 16] Device or resource busy: '/var/log/letsencrypt/.certbot.lock' 2019-12-03 01:06:00,199:DEBUG:certbot.util:Exception occurred releasing lock: LockFile(/etc/letsencrypt/.certbot.lock) <released> Traceback (most recent call last): File "/usr/lib/python3/dist-packages/certbot/util.py", line 141, in _release_locks dir_lock.release() File "/usr/lib/python3/dist-packages/certbot/lock.py", line 122, in release compat.release_locked_file(self._fd, self._path) File "/usr/lib/python3/dist-packages/certbot/compat.py", line 154, in release_locked_file os.remove(path) OSError: [Errno 16] Device or resource busy: '/etc/letsencrypt/.certbot.lock'

Wonder if anyone has got this before, I had a quick look and could not see this kind of error.

The cert then creates itself in the "SSL Certificates" tab with an expiry of approx same date and time when I clicked the "Save" button.

Originally created by @HNGamingUK on GitHub (Dec 3, 2019). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/250 Hello, So when I go to create a new SSL Certificate within the "SSL Certificates" tab or via Proxy Hosts, it loads for sometime and then just provides "Internal Error" Looking in /var/log/letsencrypt.log I found the following at the bottom: `2019-12-03 01:05:58,272:DEBUG:certbot.storage:Archive directory /etc/letsencrypt/archive/npm-6 and live directory /etc/letsencrypt/live/npm-6 created. 2019-12-03 01:05:58,274:DEBUG:certbot.log:Exiting abnormally: Traceback (most recent call last): File "/usr/bin/certbot", line 11, in <module> load_entry_point('certbot==0.28.0', 'console_scripts', 'certbot')() File "/usr/lib/python3/dist-packages/certbot/main.py", line 1340, in main return config.func(config, plugins) File "/usr/lib/python3/dist-packages/certbot/main.py", line 1225, in certonly lineage = _get_and_save_cert(le_client, config, domains, certname, lineage) File "/usr/lib/python3/dist-packages/certbot/main.py", line 121, in _get_and_save_cert lineage = le_client.obtain_and_enroll_certificate(domains, certname) File "/usr/lib/python3/dist-packages/certbot/client.py", line 410, in obtain_and_enroll_certificate self.config) File "/usr/lib/python3/dist-packages/certbot/storage.py", line 1053, in new_lineage target[kind]) OSError: [Errno 95] Operation not supported: '../../archive/npm-6/cert1.pem' -> '/etc/letsencrypt/live/npm-6/cert.pem' 2019-12-03 01:05:58,278:ERROR:certbot.log:An unexpected error occurred: 2019-12-03 01:05:59,238:DEBUG:certbot.util:Exception occurred releasing lock: LockFile(/var/log/letsencrypt/.certbot.lock) <released> Traceback (most recent call last): File "/usr/lib/python3/dist-packages/certbot/util.py", line 141, in _release_locks dir_lock.release() File "/usr/lib/python3/dist-packages/certbot/lock.py", line 122, in release compat.release_locked_file(self._fd, self._path) File "/usr/lib/python3/dist-packages/certbot/compat.py", line 154, in release_locked_file os.remove(path) OSError: [Errno 16] Device or resource busy: '/var/log/letsencrypt/.certbot.lock' 2019-12-03 01:06:00,199:DEBUG:certbot.util:Exception occurred releasing lock: LockFile(/etc/letsencrypt/.certbot.lock) <released> Traceback (most recent call last): File "/usr/lib/python3/dist-packages/certbot/util.py", line 141, in _release_locks dir_lock.release() File "/usr/lib/python3/dist-packages/certbot/lock.py", line 122, in release compat.release_locked_file(self._fd, self._path) File "/usr/lib/python3/dist-packages/certbot/compat.py", line 154, in release_locked_file os.remove(path) OSError: [Errno 16] Device or resource busy: '/etc/letsencrypt/.certbot.lock'` Wonder if anyone has got this before, I had a quick look and could not see this kind of error. The cert then creates itself in the "SSL Certificates" tab with an expiry of approx same date and time when I clicked the "Save" button.
kerem closed this issue 2026-02-26 06:31:35 +03:00
Author
Owner

@s4b3rt0oth commented on GitHub (Dec 9, 2019):

Have you tried restarting your proxy? I'd be interested to see if that resolves the lock issues. It looks like certbot hung on a bad file lock.

<!-- gh-comment-id:563028302 --> @s4b3rt0oth commented on GitHub (Dec 9, 2019): Have you tried restarting your proxy? I'd be interested to see if that resolves the lock issues. It looks like certbot hung on a bad file lock.
Author
Owner

@stephane-r commented on GitHub (Dec 22, 2019):

Hi guys !

I've the same error on fresh install. I've try to restart my nginx-proxy-manager container, but same result too :(

Anyone have already this issue ? I see many issue with internal error message

<!-- gh-comment-id:568260137 --> @stephane-r commented on GitHub (Dec 22, 2019): Hi guys ! I've the same error on fresh install. I've try to restart my nginx-proxy-manager container, but same result too :( Anyone have already this issue ? I see many issue with internal error message
Author
Owner

@stk21 commented on GitHub (Jan 25, 2020):

I have a question. I have a brand new install pulled from docker. I have setup on single proxy host and I want to give it a ssl cert. I understand the process and everything, however since the cert will be installed on the actual proxy server itself, shouldnt the acme challenge be captured on the nginx proxy server.

Cert bot is operating on the nginx proxy server, and generating the token, but the request from lets encrypt is making it all the way down to my stand alone apache/php container, and its getting a 404 error.

in the logs it shows that the token is being generated and put into the /data/letsencrypt-acme-challenge on the proxy server, but the lets encrypt request is not hitting that and I can see it hitting the logs on the apache container.

Please advise if I have missed a simple step somewhere.

Thanks. I am happy to provide any logs that are required. I have tried this in two different DMZs with different domains, all of which I control.

<!-- gh-comment-id:578371684 --> @stk21 commented on GitHub (Jan 25, 2020): I have a question. I have a brand new install pulled from docker. I have setup on single proxy host and I want to give it a ssl cert. I understand the process and everything, however since the cert will be installed on the actual proxy server itself, shouldnt the acme challenge be captured on the nginx proxy server. Cert bot is operating on the nginx proxy server, and generating the token, but the request from lets encrypt is making it all the way down to my stand alone apache/php container, and its getting a 404 error. in the logs it shows that the token is being generated and put into the /data/letsencrypt-acme-challenge on the proxy server, but the lets encrypt request is not hitting that and I can see it hitting the logs on the apache container. Please advise if I have missed a simple step somewhere. Thanks. I am happy to provide any logs that are required. I have tried this in two different DMZs with different domains, all of which I control.
Author
Owner

@jc21 commented on GitHub (Jan 25, 2020):

It’s possible that the letsencypt acme challenge URL has changed on letsencypt’s side, but I recently issued some certs a day ago and it was fine. Send me the path that the challenge came in on, as the nginx server should be intercepting it.

<!-- gh-comment-id:578377683 --> @jc21 commented on GitHub (Jan 25, 2020): It’s possible that the letsencypt acme challenge URL has changed on letsencypt’s side, but I recently issued some certs a day ago and it was fine. Send me the path that the challenge came in on, as the nginx server should be intercepting it.
Author
Owner

@stk21 commented on GitHub (Jan 25, 2020):

Thanks for the reply.

Here are the apache logs from the attempt I did last night

192.168.21.30 - - [25/Jan/2020:00:13:55 +0000] "GET /.well-known/acme-challenge/rz8_W4T9cxmPsHehV8Llds2FpsxoRoauL-wV2GkJHJo HTTP/1.0" 404 455 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
192.168.21.30 - - [25/Jan/2020:00:13:55 +0000] "GET /.well-known/acme-challenge/rz8_W4T9cxmPsHehV8Llds2FpsxoRoauL-wV2GkJHJo HTTP/1.0" 404 455 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
192.168.21.30 - - [25/Jan/2020:00:13:55 +0000] "GET /.well-known/acme-challenge/rz8_W4T9cxmPsHehV8Llds2FpsxoRoauL-wV2GkJHJo HTTP/1.0" 404 455 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)”

Here is a snippet from the letsencrypt.log file on the nginx server as well.

{
"identifier": {
"type": "dns",
"value": "kraken.i234.me"
},
"status": "invalid",
"expires": "2020-02-01T00:13:55Z",
"challenges": [
{
"type": "http-01",
"status": "invalid",
"error": {
"type": "urn:ietf:params:acme:error:unauthorized",
"detail": "Invalid response from http://kraken.i234.me/.well-known/acme-challenge/rz8_W4T9cxmPsHehV8Llds2FpsxoRoauL-wV2GkJHJo [71.218.78.21]: "\u003c!DOCTYPE HTML PUBLIC \
"-//IETF//DTD HTML 2.0//EN\"\u003e\n\u003chtml\u003e\u003chead\u003e\n\u003ctitle\u003e404 Not Found\u003c/title\u003e\n\u003c/head\u003e\u003cbody\u003e\n\u003ch1\u003eNot F
ound\u003c/h1\u003e\n\u003cp"",
"status": 403
},
"url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/2456630374/YhAFnQ",
"token": "rz8_W4T9cxmPsHehV8Llds2FpsxoRoauL-wV2GkJHJo",
"validationRecord": [
{
"url": "http://kraken.i234.me/.well-known/acme-challenge/rz8_W4T9cxmPsHehV8Llds2FpsxoRoauL-wV2GkJHJo",
"hostname": "kraken.i234.me",
"port": "80",
"addressesResolved": [
"71.218.78.21"
],
"addressUsed": "71.218.78.21"
}
]
}
]
}

Doug Moore
mooredo@gmail.com

On Jan 24, 2020, at 10:06 PM, jc21 notifications@github.com wrote:

It’s possible that the letsencypt acme challenge URL has changed on letsencypt’s side, but I recently issued some certain a day ago and it was fine. Send me the path that the challenge came in on, as the nginx server should be intercepting it.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/jc21/nginx-proxy-manager/issues/250?email_source=notifications&email_token=AH2NWVCIL7G53KS75D7NJ23Q7PCEXA5CNFSM4JUP6UO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ4VPUY#issuecomment-578377683, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH2NWVF56DRJ6LR3C4A75JTQ7PCEXANCNFSM4JUP6UOQ.

<!-- gh-comment-id:578413652 --> @stk21 commented on GitHub (Jan 25, 2020): Thanks for the reply. Here are the apache logs from the attempt I did last night 192.168.21.30 - - [25/Jan/2020:00:13:55 +0000] "GET /.well-known/acme-challenge/rz8_W4T9cxmPsHehV8Llds2FpsxoRoauL-wV2GkJHJo HTTP/1.0" 404 455 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)" 192.168.21.30 - - [25/Jan/2020:00:13:55 +0000] "GET /.well-known/acme-challenge/rz8_W4T9cxmPsHehV8Llds2FpsxoRoauL-wV2GkJHJo HTTP/1.0" 404 455 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)" 192.168.21.30 - - [25/Jan/2020:00:13:55 +0000] "GET /.well-known/acme-challenge/rz8_W4T9cxmPsHehV8Llds2FpsxoRoauL-wV2GkJHJo HTTP/1.0" 404 455 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)” Here is a snippet from the letsencrypt.log file on the nginx server as well. { "identifier": { "type": "dns", "value": "kraken.i234.me" }, "status": "invalid", "expires": "2020-02-01T00:13:55Z", "challenges": [ { "type": "http-01", "status": "invalid", "error": { "type": "urn:ietf:params:acme:error:unauthorized", "detail": "Invalid response from http://kraken.i234.me/.well-known/acme-challenge/rz8_W4T9cxmPsHehV8Llds2FpsxoRoauL-wV2GkJHJo [71.218.78.21]: \"\u003c!DOCTYPE HTML PUBLIC \\ \"-//IETF//DTD HTML 2.0//EN\\\"\u003e\\n\u003chtml\u003e\u003chead\u003e\\n\u003ctitle\u003e404 Not Found\u003c/title\u003e\\n\u003c/head\u003e\u003cbody\u003e\\n\u003ch1\u003eNot F ound\u003c/h1\u003e\\n\u003cp\"", "status": 403 }, "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/2456630374/YhAFnQ", "token": "rz8_W4T9cxmPsHehV8Llds2FpsxoRoauL-wV2GkJHJo", "validationRecord": [ { "url": "http://kraken.i234.me/.well-known/acme-challenge/rz8_W4T9cxmPsHehV8Llds2FpsxoRoauL-wV2GkJHJo", "hostname": "kraken.i234.me", "port": "80", "addressesResolved": [ "71.218.78.21" ], "addressUsed": "71.218.78.21" } ] } ] } Doug Moore mooredo@gmail.com > On Jan 24, 2020, at 10:06 PM, jc21 <notifications@github.com> wrote: > > It’s possible that the letsencypt acme challenge URL has changed on letsencypt’s side, but I recently issued some certain a day ago and it was fine. Send me the path that the challenge came in on, as the nginx server should be intercepting it. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub <https://github.com/jc21/nginx-proxy-manager/issues/250?email_source=notifications&email_token=AH2NWVCIL7G53KS75D7NJ23Q7PCEXA5CNFSM4JUP6UO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ4VPUY#issuecomment-578377683>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AH2NWVF56DRJ6LR3C4A75JTQ7PCEXANCNFSM4JUP6UOQ>. >
Author
Owner

@jc21 commented on GitHub (Jan 27, 2020):

The LE path hasn't changed and it would definitely be intercepted by NPM and should not be passed upstream at all. But I can see that's somehow not the case. Have you defined anything extra in the Advanced configuration for your host at all?

<!-- gh-comment-id:578988260 --> @jc21 commented on GitHub (Jan 27, 2020): The LE path hasn't changed and it would definitely be intercepted by NPM and should not be passed upstream at all. But I can see that's somehow not the case. Have you defined anything extra in the Advanced configuration for your host at all?
Author
Owner

@stk21 commented on GitHub (Jan 27, 2020):

Nothing. However I am going to start over from scratch and see if I can redo this. I did it all once, got errors, then quickly did it again and got the same results. Third try later this evening perhaps with a clearer head this time.

I will let you know the outcome either way.

Thanks
Doug

On Jan 27, 2020, at 3:35 PM, jc21 notifications@github.com wrote:

The LE path hasn't changed and it would definitely be intercepted by NPM and should not be passed upstream at all. But I can see that's somehow not the case. Have you defined anything extra in the Advanced configuration for your host at all?


You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/jc21/nginx-proxy-manager/issues/250?email_source=notifications&email_token=AH2NWVEWNSHYZLLYKXMGX4TQ75ORLA5CNFSM4JUP6UO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKBKRZA#issuecomment-578988260, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH2NWVHKUCU37ZQS56SBAU3Q75ORLANCNFSM4JUP6UOQ.

<!-- gh-comment-id:578999070 --> @stk21 commented on GitHub (Jan 27, 2020): Nothing. However I am going to start over from scratch and see if I can redo this. I did it all once, got errors, then quickly did it again and got the same results. Third try later this evening perhaps with a clearer head this time. I will let you know the outcome either way. Thanks Doug > On Jan 27, 2020, at 3:35 PM, jc21 <notifications@github.com> wrote: > > The LE path hasn't changed and it would definitely be intercepted by NPM and should not be passed upstream at all. But I can see that's somehow not the case. Have you defined anything extra in the Advanced configuration for your host at all? > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub <https://github.com/jc21/nginx-proxy-manager/issues/250?email_source=notifications&email_token=AH2NWVEWNSHYZLLYKXMGX4TQ75ORLA5CNFSM4JUP6UO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKBKRZA#issuecomment-578988260>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AH2NWVHKUCU37ZQS56SBAU3Q75ORLANCNFSM4JUP6UOQ>. >
Author
Owner

@stk21 commented on GitHub (Jan 29, 2020):

So. Not sure what I did different the third and fourth time, but I have everything working in both of my sites now. Thanks for looking into this and making a great tool.

Doug

On Jan 27, 2020, at 4:07 PM, Doug Moore mooredo@gmail.com wrote:

Nothing. However I am going to start over from scratch and see if I can redo this. I did it all once, got errors, then quickly did it again and got the same results. Third try later this evening perhaps with a clearer head this time.

I will let you know the outcome either way.

Thanks
Doug

On Jan 27, 2020, at 3:35 PM, jc21 <notifications@github.com mailto:notifications@github.com> wrote:

The LE path hasn't changed and it would definitely be intercepted by NPM and should not be passed upstream at all. But I can see that's somehow not the case. Have you defined anything extra in the Advanced configuration for your host at all?


You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/jc21/nginx-proxy-manager/issues/250?email_source=notifications&email_token=AH2NWVEWNSHYZLLYKXMGX4TQ75ORLA5CNFSM4JUP6UO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKBKRZA#issuecomment-578988260, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH2NWVHKUCU37ZQS56SBAU3Q75ORLANCNFSM4JUP6UOQ.

<!-- gh-comment-id:579875136 --> @stk21 commented on GitHub (Jan 29, 2020): So. Not sure what I did different the third and fourth time, but I have everything working in both of my sites now. Thanks for looking into this and making a great tool. Doug > On Jan 27, 2020, at 4:07 PM, Doug Moore <mooredo@gmail.com> wrote: > > Nothing. However I am going to start over from scratch and see if I can redo this. I did it all once, got errors, then quickly did it again and got the same results. Third try later this evening perhaps with a clearer head this time. > > I will let you know the outcome either way. > > Thanks > Doug > > > > >> On Jan 27, 2020, at 3:35 PM, jc21 <notifications@github.com <mailto:notifications@github.com>> wrote: >> >> The LE path hasn't changed and it would definitely be intercepted by NPM and should not be passed upstream at all. But I can see that's somehow not the case. Have you defined anything extra in the Advanced configuration for your host at all? >> >> — >> You are receiving this because you commented. >> Reply to this email directly, view it on GitHub <https://github.com/jc21/nginx-proxy-manager/issues/250?email_source=notifications&email_token=AH2NWVEWNSHYZLLYKXMGX4TQ75ORLA5CNFSM4JUP6UO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKBKRZA#issuecomment-578988260>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AH2NWVHKUCU37ZQS56SBAU3Q75ORLANCNFSM4JUP6UOQ>. >> >
Author
Owner

@inakianduaga commented on GitHub (Jan 29, 2020):

A bit related to this, my nginx server is failing to boot up when I enabled a let's encrypt certificate (it can generate one but it's expired on the same date I click save). Here's the log

[1/29/2020] [10:06:07 PM] [SSL      ] › ℹ  info      Renewing Let'sEncrypt certificates for Cert #2: REDACTED.duckdns.org
[1/29/2020] [10:06:09 PM] [Express  ] › ⚠  warning   Command failed: /usr/bin/certbot renew -n --force-renewal --disable-hook-validation --cert-name "npm-2" 
Saving debug log to /data/logs/letsencrypt/letsencrypt.log
No certificate found with name npm-2 (expected /etc/letsencrypt/renewal/npm-2.conf).
[1/29/2020] [10:37:39 PM] [SSL      ] › ℹ  info      Renewing SSL certs close to expiry...
[1/29/2020] [10:37:41 PM] [SSL      ] › ℹ  info      
[1/29/2020] [10:37:41 PM] [Nginx    ] › ℹ  info      Reloading Nginx
[1/29/2020] [10:37:41 PM] [SSL      ] › ℹ  info      Renew Complete
[1/29/2020] [10:37:41 PM] [SSL      ] › ✖  error     Certificate is not valid (Command failed: openssl x509 -in /etc/letsencrypt/live/npm-1/fullchain.pem -subject -noout
Can't open /etc/letsencrypt/live/npm-1/fullchain.pem for reading, No such file or directory
3069769048:error:02001002:system library:fopen:No such file or directory:crypto/bio/bss_file.c:69:fopen('/etc/letsencrypt/live/npm-1/fullchain.pem','r')
3069769048:error:2006D080:BIO routines:BIO_new_file:no such file:crypto/bio/bss_file.c:76:
unable to load certificate
)
<!-- gh-comment-id:580000811 --> @inakianduaga commented on GitHub (Jan 29, 2020): A bit related to this, my nginx server is failing to boot up when I enabled a `let's encrypt` certificate (it can generate one but it's expired on the same date I click save). Here's the log ``` [1/29/2020] [10:06:07 PM] [SSL ] › ℹ info Renewing Let'sEncrypt certificates for Cert #2: REDACTED.duckdns.org [1/29/2020] [10:06:09 PM] [Express ] › ⚠ warning Command failed: /usr/bin/certbot renew -n --force-renewal --disable-hook-validation --cert-name "npm-2" Saving debug log to /data/logs/letsencrypt/letsencrypt.log No certificate found with name npm-2 (expected /etc/letsencrypt/renewal/npm-2.conf). [1/29/2020] [10:37:39 PM] [SSL ] › ℹ info Renewing SSL certs close to expiry... [1/29/2020] [10:37:41 PM] [SSL ] › ℹ info [1/29/2020] [10:37:41 PM] [Nginx ] › ℹ info Reloading Nginx [1/29/2020] [10:37:41 PM] [SSL ] › ℹ info Renew Complete [1/29/2020] [10:37:41 PM] [SSL ] › ✖ error Certificate is not valid (Command failed: openssl x509 -in /etc/letsencrypt/live/npm-1/fullchain.pem -subject -noout Can't open /etc/letsencrypt/live/npm-1/fullchain.pem for reading, No such file or directory 3069769048:error:02001002:system library:fopen:No such file or directory:crypto/bio/bss_file.c:69:fopen('/etc/letsencrypt/live/npm-1/fullchain.pem','r') 3069769048:error:2006D080:BIO routines:BIO_new_file:no such file:crypto/bio/bss_file.c:76: unable to load certificate ) ```
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/nginx-proxy-manager-NginxProxyManager#218
No description provided.