Wrong timestamps logged for new certificate

Help
1

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:
share.insidertools.de

I ran this command:
sudo certbot certonly --nginx -d share.insidertools.de

It produced this output:
What would you like to do?

1: Keep the existing certificate for now
2: Renew & replace the cert (limit ~5 per 7 days)

Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Renewing an existing certificate

IMPORTANT NOTES:

  • Congratulations! Your certificate and chain have been saved at:
    /etc/letsencrypt/live/share.insidertools.de/fullchain.pem
    Your key file has been saved at:
    /etc/letsencrypt/live/share.insidertools.de/privkey.pem
    Your cert will expire on 2023-11-17. To obtain a new or tweaked
    version of this certificate in the future, simply run certbot
    again. To non-interactively renew all of your certificates, run
    "certbot renew"

  • If you like Certbot, please consider supporting our work by:

    Donating to ISRG / Let's Encrypt: Donate - Let's Encrypt
    Donating to EFF: Support EFF's Work on Let's Encrypt | Electronic Frontier Foundation

My web server is (include version):
nginx version: nginx/1.18.0 (Ubuntu)

The operating system my web server runs on is (include version):
Operating System: Ubuntu 20.04.6 LTS
Kernel: Linux 5.4.0
Architecture: x86-64

My hosting provider, if applicable, is:
strato

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.40.0

Hello, I just recreated my certificate a few minutes ago. It is this certificate: crt.sh | 9870232335

Today is the 19.08.2023. On the console it shows me that the certificate would expire on 17.11.2023. This time is also given to me when I type "sudo certbot certificates -d share.insidertools.de". The time on my server is correct. I have updated all packages and renewed the certificate again. The result remains the same: the actual certificate delivered to the browser contains wrong time information. According to this, the certificate was issued on 07/06/2023 and is valid until 10/04/2023.

These times (with 2h difference due to the time zone) are also on crt.sh. How can there be a creation date that is far in the past? I think this is a mistake. If this was intended, it was not fully thought out, because my server keeps the information that the certificate is valid until 17.11.2023 and therefore does not renew when it is needed. I just became aware of this because the previous certificate was already not renewed even though the browser reported it as expired.

2

This is a July 6th or 7th certificate.

Issued July, expires April? You m/d/y people!

Yes, that's the certificate.

You know you have to install newer certificates if you want to use them, right?

4 Likes
3

Why would you assume the creation date is actually in the past if your "console" (what's that?) shows a correct expiry date 3 months from now and sudo certbot certificates shows that too? Because to me, those clues are telling you that the date of the issued certificate is actually very much correct?

and:

You're using a VERY old version of Certbot and you're using the certonly subcommand. With Certbot versions older than 1.27.0, your webserver wouldn't restart when using the certonly subcommand. See https://github.com/certbot/certbot/blob/master/certbot/CHANGELOG.md#changed-13 for the CHANGELOG entry about that.

Now, what puzzles me, is that you're forcing re-issuance of the certificate by chosing option 2 at the "What would you like to do?" question. Now, because this is NOT an issuance issue, chosing "2" was utterly useless, as this is clearly some webserver certificate installation issue. But that useless re-issuane using the --nginx authenticator plugin should have lead to reloading nginx to load the challenge and thus should also load the earlier renewed certificate. So I still don't understand it completely.

You may want to try to manually reload nginx and see if that loads the new certificate.

If that didn't work, we'd need to take a look at your nginx configuration regarding the TLS settings.

Yeah, I don't understand that either.. :roll_eyes: Although looking at the .de TLD, OP might be German? And AFAIK German uses the correct date notation like almost everybody in the world does?

3 Likes
4

ISO 8601 YYYY-MM-DD is the only date format that can be considered correct. All others are ambiguous and wrong, no matter how widespread or popular their usage may be. :grinning:

5 Likes
5

Offtopic: well, yeah, but there are grades of wrong: there's "slightly wrong, but still makes sense" (dd-mm-yyyy) and there's "what were you drinking/smoking/snorting/stickingLSD/eating" kinda wrong (mm/dd/yyyy) :wink:

1 Like
6

I must apologize. You are absolutely right about the timing. I have to admit that I translated parts of the text with deepl.com out of laziness. In doing so, the date format was reversed. I agree that yyyy/mm/dd is the only sensible format, as this is the only way to ensure a correct order.

So the time information once again clearly in yyyy/mm/dd:
Requested: 2023/08/19
According to certbot valid until: 2023/11/17
This information makes sense and should be correct.

Entry under crt.sh:
Not Before: 2023/07/06
Not After: 2023/10/04

This is the last entry for the domain. Apparently the registry is just not quite up to date. Restarting nginx actually fixed the problem.

I didn't know that nginx keeps the certificates in memory. Then now I just need to see how to configure nginx to restart when the certificates are renewed. Apparently this doesn't happen automatically. So my first concern is solved.

As for the configuration, I use a snippet in each server block that directly returns the file for the acme challenge on certificate renewal.

location ^~ /.well-known/acme-challenge/ {
  allow all;
  root /var/lib/letsencrypt/;
  default_type "text/plain";
  try_files $uri =404;
}

The --nginx option should ensure that the currently running web server is used. So it will not be shut down for the renewal. I probably have to additionally define that it should be restarted once afterwards.
However, I would prefer to be able to define a small script that first checks the configuration with "nginx -t" and only restarts nginx if the check is ok. Otherwise I would let the script notify me about a faulty configuration.

Edit: I was just thinking that I could have nginx restart periodically in general. Then a cronjob would do it as well. Do you know if there are any performance or memory usage reasons why you should do this regularly anyway? Otherwise, the web server runs continuously for me.

1 Like
7

no point, you can tell certbot to reload/restart whatever you want.

  --deploy-hook DEPLOY_HOOK
                        Command to be run in a shell once for each
                        successfully issued certificate. Unless --disable-
                        hook-validation is used, the command’s first word must
                        be the absolute pathname of an executable or one found
                        via the PATH environment variable. For this command,
                        the shell variable $RENEWED_LINEAGE will point to the
                        config live subdirectory (for example,
                        "/etc/letsencrypt/live/example.com") containing the
                        new certificates and keys; the shell variable
                        $RENEWED_DOMAINS will contain a space-delimited list
                        of renewed certificate domains (for example,
                        "example.com www.example.com") (default: None)

https://eff-certbot.readthedocs.io/en/stable/using.html#certbot-command-line-options

5 Likes
8

An nginx reload is all that is needed. The deploy hook that 9peppe described is a good method. Or you could even just do it daily in a cron job. It is not disruptive to nginx operations. I usually use:
sudo systemctl reload nginx

http://nginx.org/en/docs/beginners_guide.html

Also, crt.sh often lags by as much as 24 hours and sometimes more.

5 Likes
9

Also know that certificate start and end dates are UTC, not your local time.

2 Likes
10

Unless...
Your local time zone is UTC - LOL

4 Likes
11

interestingly only the yellow areas are synched up to UTC year-round (meaning they have no DST)

image
image1920×1027 275 KB

dark blue areas match UTC only part of the year

then you have oddballs like France and Spain who intentionally use the wrong time zone in order to match up with most of Europe

7 Likes
12

Off-topic fun fact: in Australia we have places who's timezone are different by 45 minutes, or more commonly 30 minutes. There were definitely no software developers involved in that decision and that's why you can't use an integer for timezone [hour] offsets.

5 Likes
13

Well hopefully at least integer number of minutes can work. It would be bad if if integer seconds doesn't work. :rofl:

3 Likes
14

And Australia isn't even the only place that happens :smiley:

5 Likes
15

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