Reuse existing certificates on Raspberry Pi Nextcloud Server

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. crt.sh | 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: elferteriu.sytes.net

I ran this command: None, as I could not see any supporting my usecase

It produced this output:
[Wed Apr 20 20:01:46.883606 2022] [ssl:warn] [pid 1007:tid 548261574016] AH01909: elferteriu.sytes.net:4443:0 server certificate does NOT include an ID which matches the server name
[Wed Apr 20 20:01:46.890610 2022] [ssl:error] [pid 1007:tid 548261574016] AH02217: ssl_stapling_init_cert: can't retrieve issuer certificate! [subject: CN=archlinux / issuer: CN=archlinux / serial: 18C088C8F787E3CFD6C7C76280DC1F392C6E3DC2 / notbefore: Oct 8 19:39:52 2021 GMT / notafter: Oct 6 19:39:52 2031 GMT]

My web server is (include version): Apache 2.4.38

The operating system my web server runs on is (include version): Debian 11 (bullseye)

My hosting provider, if applicable, is: None

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): can't tell yet

I want to reuse the provided key and certificates of my last REGULAR update.
By copying them into the letsencrypt archive path and symlink them from the live path they are not recognized by using
certbot certificates
For Apache they are defined, but somehow they are not accepted.

Is there a way to tell certbot and letsencrypt that there are already certificates available?

Welcome to the community @MASH4077

I see you have 10 valid certificates outstanding. You started getting certs in May 2021. What happened recently to create your current problem?

Could you show the results of these commands:

certbot --version
apachectl -S

Also, right now I cannot reach your server on port 80 or 443. Is Apache running and is your firewall open?

2 Likes

Hello MikeMcQ,

honestly, I am still searching for the configuration setting of the 60 to 90 days within certbot.

Recently I updated my NextcloudPi Server to version 1.47.1, but that ended up in a total mess (bullseye wasn't updated by then, it ran on buster).

Now I set up a new NextCloudPi Server with bullseye and I would like to import the certificates and keys from my former letsencrypt folders to the new one.

I set my server back online, but without a valid certificate (only selfsigned!).

certbot --version --> certbot 1.12.0
apachectl -S -->
VirtualHost configuration:
*:80 localhost (/etc/apache2/sites-enabled/000-default.conf:1)
*:4443 localhost (/etc/apache2/sites-enabled/ncp.conf:2)
*:443 localhost (/etc/apache2/sites-enabled/nextcloud.conf:4)
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex watchdog-callback: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex ssl-stapling: using_defaults
Mutex proxy: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/var/run/apache2/" mechanism=default
PidFile: "/var/run/apache2/apache2.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="www-data" id=33
Group: name="www-data" id=33

Instead of copying just your certs can you copy over your entire /etc/letsencrypt folders?

If not then I think you should start fresh with certbot on your new server. But, you will need to wait another day to get a good cert as you are Rate Limited. You could use --dry-run to test the setup or --test-cert depending on the certbot command you used.

2 Likes

Perhaps Certbot could be improved by a separate command to reinstall an active certificate.

The use-cases would be:

  • A user backed-up or transferred their /etc/letsencrypt directory, but does not have a configured webserver.
  • A user has an active /etc/letsencrypt directory under one webserver (e.g. Apache), and decides to switch to a new webserver (e.g. Nginx)

In these situations, Certbot has active certificates accessible and simply needs to run the installer plugins.

Such a command could also help users who had trouble installing a certificate on version X of Cerbot, however version Y introduces a fix.

1 Like

I was about to file a Feature Request against Certbot and found this in the docs:

automation:
  Flags for automating execution & other tweaks

  --keep-until-expiring, --keep, --reinstall
                        If the requested certificate matches an existing
                        certificate, always keep the existing one until it is
                        due for renewal (for the 'run' subcommand this means
                        reinstall the existing certificate). (default: Ask)

Shouldn't --reinstall handle this situation as it is currently implemented? If so, this would solve a lot of problems I have seen in this forum.

@_az Would you be able to chime in on this?

1 Like

I think their renewal folder is missing. That is why certbot certificates fails. This reinstall won't help that (afaik). Plus, they talked about adjusting the symlinks so hard to assess what impact that may have. I think a clean start is best but of course you or anyone can help them with an alternate solution.

2 Likes

Of course. My concern is if they follow your earlier advice:

I never noticed the --reinstall, etc commands before. Searching this forum, I saw that it's been suggested 50+ times – but I recall many more situations within the past few weeks where it would have been appropriate.

1 Like

Usually, Certbot asks the user what to do, reinstall or re-issue.

2 Likes

Doesn't certbot actually have an install subcommand?

2 Likes

It wasn't advice, it was a question. The answer would lead the subsequent steps

2 Likes

It does indeed.

4 Likes

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