Had to reinstall letsencrypt. How do I get it to use my certs?

I’ve been running nexcloudpi on my PI model 3 for about 6 months using letsencrypt to handle the certs.

For some mysterious reason, letsencrypt got uninstalled a couple of months ago (perhaps during an upgrade?) without my knowlege (or ignorance!).

I’d like to get letsencrypt running again. I tried re-installing it (apt install letsencrypt) with no affect.
I still have all of the cert files in:

ls -l /etc/letsencrypt/live/inchoateimages.duckdns.org/
total 4
lrwxrwxrwx 1 root root 50 Dec 21 17:03 cert.pem -> …/…/archive/inchoateimages.duckdns.org/cert2.pem
lrwxrwxrwx 1 root root 51 Dec 21 17:03 chain.pem -> …/…/archive/inchoateimages.duckdns.org/chain2.pem
lrwxrwxrwx 1 root root 55 Dec 21 17:03 fullchain.pem -> …/…/archive/inchoateimages.duckdns.org/fullchain2.pem
lrwxrwxrwx 1 root root 53 Dec 21 17:03 privkey.pem -> …/…/archive/inchoateimages.duckdns.org/privkey2.pem
-rw-r–r-- 1 root root 543 Oct 16 18:14 README

What do I need to do to get this restored?

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:
apt install letsencrypt

certbot renew --dry-run

It produced this output:

root@cloud:/var/log# certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log


** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates below have not been saved.)

No renewals were attempted.
** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates above have not been saved.)


My web server is (include version):
Server version: Apache/2.4.25 (Raspbian)

The operating system my web server runs on is (include version):
Raspbian GNU/Linux 9 (stretch)

My hosting provider, if applicable, is:
-na-

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

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

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

Thanks!

Hi @inchoate

you have a valid certificate (via https://check-your-website.server-daten.de/?q=inchoateimages.duckdns.org ):

CN=inchoateimages.duckdns.org
	22.12.2018
	22.03.2019
expires in 6 days	inchoateimages.duckdns.org - 1 entry

But the missing output of certbot renew --dry-run looks that Certbot can't find that certificate.

Create a new certificate:

certbot -d inchoateimages.duckdns.org

But: Your configuration is critical:

Domainname Http-Status redirect Sec. G
http://inchoateimages.duckdns.org/
50.53.9.56 302 https://inchoateimages.duckdns.org/ 0.357 A
http://www.inchoateimages.duckdns.org/
50.53.9.56 302 https://www.inchoateimages.duckdns.org/ 0.384 A
https://inchoateimages.duckdns.org/
50.53.9.56 302 Nextcloud 2.650 A
https://www.inchoateimages.duckdns.org/
50.53.9.56 400 2.480 N
Bad Request
Certificate error: RemoteCertificateNameMismatch
Nextcloud 200 2.107 A
Nextcloud
50.53.9.56 302 Nextcloud 0.363 A
Visible Content: Found The document has moved here .
http://www.inchoateimages.duckdns.org/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
50.53.9.56 302 https://www.inchoateimages.duckdns.org/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de 0.383 A
Visible Content: Found The document has moved here .
Nextcloud 302 Nextcloud 1.963 A
Visible Content:
https://www.inchoateimages.duckdns.org/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de -14 10.027 T
Timeout - The operation has timed out

You can ignore the www - version, that's not relevant. But your non-www /.well-known/acme-challenge is redirected to https (that's ok), then redirected to your login page (that's bad).

So Letsencrypt can't find the validation file.

Easiest solution: Check your http vHost (port 80) and (1) remove the redirect or (2) add an exception, so /.well-known/acme-challenge isn't redirected.

Thanks for the response!

Can you tell me which file(s) I would find this in? I'm not too familiar with web site configuration.

Can anyone tell me how to make these changes? Specifically, which config file I need to look at?
I'm pretty green at web config.
Thanks

Please check the basics:

/etc/apache2/
|-- apache2.conf
|       `--  ports.conf
|-- mods-enabled
|       |-- *.load
|       `-- *.conf
|-- conf-enabled
|       `-- *.conf
|-- sites-enabled
|       `-- *.conf

That’s one standard configuration. But it’s possible that you have another configuration, so you may not find the files there.

I would suggest running certbot certificates to see if Certbot agrees that you still have some certificates. If so, you might then be able to get Certbot to reinstall this certificate in your Apache configuration by re-running Certbot and asking for the exact same domain names.

No certs found unfortunately.

It seems like your /etc/letsencrypt backup was incomplete, so you should probably just throw away (delete) the old certificates and start from scratch with Certbot.

I think I still have the cert files:

root@cloud:/etc/letsencrypt# ll /etc/letsencrypt/live/inchoateimages.duckdns.org/
total 12
drwxr-xr-x 2 root root 4096 Dec 21 17:03 .
drwxr-xr-x 3 root root 4096 Oct 16 18:14 ..
lrwxrwxrwx 1 root root 50 Dec 21 17:03 cert.pem -> ../../archive/inchoateimages.duckdns.org/cert2.pem
lrwxrwxrwx 1 root root 51 Dec 21 17:03 chain.pem -> ../../archive/inchoateimages.duckdns.org/chain2.pem
lrwxrwxrwx 1 root root 55 Dec 21 17:03 fullchain.pem -> ../../archive/inchoateimages.duckdns.org/fullchain2.pem
lrwxrwxrwx 1 root root 53 Dec 21 17:03 privkey.pem -> ../../archive/inchoateimages.duckdns.org/privkey2.pem

By 'starting from scratch' do you mean

certbot -d inchoateimages.duckdns.org

Will I still be able to keep the same URL?

I’m still trying to figure out this:

You can ignore the www - version, that’s not relevant. But your non-www /.well-known/acme-challenge is redirected to https (that’s ok), then redirected to your login page (that’s bad).

So Letsencrypt can’t find the validation file.

Easiest solution: Check your http vHost (port 80) and (1) remove the redirect or (2) add an exception, so /.well-known/acme-challenge isn’t redirected.

I’ve looked at these configuration files (I had to rename them to text files to upload):
htaccess.txt (325 Bytes)
nextcloud.conf.txt (651 Bytes)
ncp.conf.txt (1.0 KB)
000-default.conf.txt (224 Bytes)
ports.conf.txt (320 Bytes)

I’m not seeing anything obvious.

Yes, and I would suggest moving all of /etc/letsencrypt somewhere else first.

Yes.

Ok, I moved /etc/letsencrypt out of the way:

certbot -d inchoateimages.duckdns.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Certbot doesn't know how to automatically configure the web server on this system. However, it can still get a certificate for you. Please run "certbot certonly" to do so. You'll need to manually configure your web server to use the resulting certificate.

Do I need to tell it I’m using apache2?

The letsencrypt directory I moved out of the way had quite a few files and directories in it. Does certbot need some of these?

Is your Apache in the standard place for your operating system? Also, do you have an existing HTTP virtual host that specifies the name inchoateimages.duckdns.org (as opposed to simply using the default virtual host)? (Certbot expects you to have existing name-based HTTP virtual hosts in order to configure your Apache installation.)

Normally yes, but it seems like the directory was in an inconsistent state and so removing it is part of starting over.

Your config files

have only default vHosts.

Add a new block in your port 80 file:

https://httpd.apache.org/docs/2.4/vhosts/examples.html

<VirtualHost *:80>
    DocumentRoot "/www/example1"
    ServerName inchoateimages.duckdns.or

    # Other directives here
</VirtualHost>

Change the DocumentRoot to your correct value.

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