Hi !
Ok now i get some response on
openssl s_client -showcerts -connect virgo.hoerst.net:4460
but a lot off error messages...
Ciao Gerd
Am 25.04.2025 um 12:34 schrieb kr...@kaffeeschluerfer.com:
Hello Gerd,
Hmm, the first thing I'd look at would probably be to double-check you're
seeing the same thing locally than what I see from the outside. I.e., make sure
that what I am seeing is not caused by some intermediate entity messing with
the communication. E.g., try something like the following, substituting your
domain name/port number:
openssl s_client -showcerts -connect ptbtime2.ptb.de:4460
Then, I guess you'd already noticed/looked for error messages in the logs, so I
assume you not mentioning anything in that regard likely means there weren't
any. If chronyd had issues reading the file, and assuming the log level that
seems the default on Debian, it would emit a message like the following:
Apr 24 15:43:06 debian chronyd[18603]: Could not set credentials : Error while
reading file.
Depending on the exact issue, there _might_ be other messages with slightly
more info, e.g.,
Apr 24 15:43:06 debian chronyd[18602]: Missing read access to
/etc/chrony/key.pem : Permission denied
(I found that there is no such additional message when chronyd cannot find the
file at all.)
So, just to be sure, double-check there aren't any error messages in the logs,
and that the ownership and permissions on the files are indeed correct.
One thing I noted when re-reading previous messages: Your snipped copies "only"
the actual server certificate, when it should be the full chain. I.e., including at least
the certificates of any intermediate issuing entities (the root certificate typically is
assumed to be available on the client already). I haven't tried that yet, but depending
on the server TLS library and how it's used, that _might_ cause a failure in setting the
needed credentials. So, if the above did not indicate another issue, using the
fullchain.pem file instead of the cert.pem one would probably be the next thing to try as
far as changing and checking whether that makes a difference goes.
Kind regards,
Joachim
25.04.2025 10:58:50 Gerd Hoerst <g...@hoerst.net>:
Hi !
Thanks a lot.... but i have actual no idea where to start with bug search...
the key is a rsa key from letsencrypt
and the setup un chrony
ntsserverkey /etc/chrony/cert/privkey.pem
ntsservercert /etc/chrony/cert/cert.pem
ntsdumpdir /var/lib/chrony
the chronyc -N serverstats says:
NTP packets received : 35975673
NTP packets dropped : 0
Command packets received : 81
Command packets dropped : 0
Client log records dropped : 15616714
NTS-KE connections accepted: 946
NTS-KE connections dropped : 0
Authenticated NTP packets : 0
Interleaved NTP packets : 110
NTP timestamps held : 2403
NTP timestamp span : 766138
NTP daemon RX timestamps : 0
NTP daemon TX timestamps : 35971583
NTP kernel RX timestamps : 35971693
NTP kernel TX timestamps : 110
NTP hardware RX timestamps : 0
NTP hardware TX timestamps : 0
Ciao Gerd
Am 24.04.2025 18:13, schrieb kr...@kaffeeschluerfer.com:
Hello Gerd,
Assuming that your intention is to run an NTS server at the domain you
shared as part of your example, just fyi that it is accepting TCP
connections, but it seems it is not accepting TLS connections on the
default NTS-KE port. In case you're running chronyd (strong likelihood
given the forum), in my experience, that can happen when chronyd is
not able to read one or more of the credential files, e.g., because
chronyd cannot find it/them in the place configured, or chronyd
doesn't have read rights for the file(s).
Kind regards,
Joachim
23.04.2025 11:37:09 kr...@kaffeeschluerfer.com:
so why don't copy them before and give them the correct right ?
Sure, but why not let the deploy hook do that as well for you?
the hook is used to restart services
Yes, if that is all you tell it to do. But it can do more than that.
The deploy hook does whatever you tell it to do, as defined by the
script one places in the deploy subfolder.
Kind regards,
Joachim
23.04.2025 11:31:04 Gerd Hoerst <g...@hoerst.net>:
Hi !
the hook is used to restart services (like apache/postfix/dovecot)
after a renewal (if there was no user right issue, you need also to
restart/reload chrony to use the new certs... so why don't copy them
before and give them the correct rights ?
Ciao Gerd
Am 22.04.25 um 23:51 schrieb kr...@kaffeeschluerfer.com:
Why just do that in the renewal-hook/post script ?
Not sure I fully grasp your drift, so apologies if the following is
old news.
The point of the certbot renewal hook is automation of deployment.
Nothing wrong with manually keeping track of the validity of existing
certificates, e.g., periodically checking, setting a reminder
somewhere, having a tool that checks and alerts, or waiting until
someone or something alerts upon finding an expired certificate (as
you will have seen, Let's encrypt will cease sending reminders in the
near future). And then deploying manually (assuming certbot did an
automated renewal, or maybe do that manually as well).
But once the number of certificates to keep track of reaches a certain
level, or the thrill of learning the ropes, i.e., setting this up in
the first place, and going through the motions of deploying manually
after (manual or automated) renewal, diminishes after a few
iterations, automated deployment (after automated renewal) is your
friend.
As always, YMMV.
Kind regards,
Joachim
22.04.2025 22:50:06 Sviatoslav Feshchenko
<sviatoslav.feshche...@proton.me>:
This seem like a simpler solution! Thank you for sharing!
Sviatoslav
On Tuesday, April 22nd, 2025 at 3:32 AM, Gerd Hoerst
<g...@hoerst.net> wrote:
Hi !
Why just do that in the renewal-hook/post script ?
cp -L /etc/letsencrypt/live/time.hoerst.net/cert.pem
/etc/chrony/cert/
cp -L /etc/letsencrypt/live/time.hoerst.net/privkey.pem
/etc/chrony/cert/
chmod g+r /etc/chrony/cert/*
systemctl restart chrony
Ciao Gerd
Am 20.04.25 um 19:40 schrieb kr...@kaffeeschluerfer.com:
…
--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email listmas...@chrony.tuxfamily.org.
