| Re: [chrony-users] NTS: Limiting |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
- To: chrony-users@xxxxxxxxxxxxxxxxxxxx
- Subject: Re: [chrony-users] NTS: Limiting
- From: Karol Babioch <karol@xxxxxxxxxx>
- Date: Tue, 19 Jan 2021 18:45:35 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=babioch.de; s=24406; t=1611078338; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kR03bZ7GTTv5QLj6HeUAUyYkneNyOUYHM3KuVFhkRhM=; b=j5rRnOp4s07LaX28yn3F/sbeLyYbg9o2Qcsz7zLKqUdYj+srK71u7OT88TT4sHNvIiS/jf 7ZUe+DkWfXPA5uFSCYkk7/061cQRPwF4OySUjvQ/dejT2qLQ80QLihoycKDZ8J+beLVccF s3xbDt0iNIl0kMSa85WVhaV37uttzzxR+QWPOOxp1odY+T5JGbjn3okhK+HiOtHDdrCRkp 4TM3hhbC8cnsTE5FYzAMOdYwg431YfJQ/stny4FxbUyoCXnpZ57AAdTE/7ZmM/9OjRkEZB 1vCuan09miJSorPLGr7zkvFreWcsBP1lHa+oaCuZxS8AoigEC9vOfr3CaLxZiw==
- Dkim-signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=babioch.de; s=43975; t=1611078338; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kR03bZ7GTTv5QLj6HeUAUyYkneNyOUYHM3KuVFhkRhM=; b=hgnPWhub6RLXDTvfDofAHcReo2xu3Ogs5/FcSnKi9BypQ8gJVjEpOijlSWhJqjsWo69KkE oSEcYMdtoYEQDzAA==
Hi all,
Am 19.01.21 um 17:03 schrieb Miroslav Lichvar:
> No, that's not currently supported. It sounds complicated. Do you
> have any examples of other TLS clients implementing such
> functionality and how their configuration looks like?
Hm, yes, this can become complicated. But one potential way of dealing
with that kind of complexity is to either make it very generic (via some
kind of expression language) and/or to "outsource" it to an external
command.
Some examples I'm aware of:
- OpenVPN (via tls-verify option):
https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
The man page actually covers the exact use-case that I have in mind here:
> This feature is useful if the peer you want to trust has a
> certificate which was signed by a certificate authority who also
> signed many other certificates, where you don't necessarily want to
> trust all of them, but rather be selective about which peer
> certificate you will accept.
- Apache (via SSLRequire):
https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslrequire (although
it seems to be deprecated)
There are probably other such implementations, essentially whenever
there is a TLS client implemented.
> If you control the specific servers signed by Let's Encrypt, maybe you
> could trust all their certificates individually and then trust all the
> system certificates except Let's Encrypt?
No, that is rather inflexible. Let's Encrypt certificates change often
(< 90 days). I don't think it's good practice to change / control the
configuration of all the downstream clients just because a certificate
was regularly rotated.
Best regards,
Karol Babioch
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.