Am 02.01.22 um 17:11 schrieb Karsten:
Basically you can install the self-signed certificate (if you or a
trusted party signed it, and you have transmitted it over a secure
channel, for instance, via SFTP or SCP) into the trust store (assuming
it suits both the TLS server and the signing CA roles - which was set
when you created it).
Just for understanding - the installation is the public certificate of the
server,
or must be a special file derived from the private certificate?
"It depends" - on how you exactly you generated it - even if you only
created it with "openssl req -x509 ...", the openssl configuration files
matter.
Normally, 1. the client's trust store (OpenSSL on the fetchmail
computer) needs the CA certificate, i. e. one with the CA flag set to
true in the basicConstraints, or basicContraints missing, see the
x509(1ssl) manual page under CERTIFICATE EXTENSIONS. 2. Then, the server
needs to present a certificate that is suitable as "SSL Server"
(extendedKeyUsage = serverAuth) role.
See the x509v3_config(5ssl) manual page for details.
If your server's certificate does not fulfill both criteria, you better
start over and set up a ca (and store its private key password-protected
in a safe place, as you seldomly need it), and a separate server cert
signed by your own ca. easy-rsa may help with that. Check
/usr/share/doc/easy-rsa, easy-rsa has README files, but no manual page.
To check:
openssl x509 -noout -text -in whatever.crt # or whatever.pem
shows you that, here for a CA certificate:
X509v3 Basic Constraints:
CA:TRUE
...
X509v3 Key Usage:
Certificate Sign, CRL Sign
The TLS server has
X509v3 Basic Constraints:
CA:FALSE
...
X509v3 Extended Key Usage:
TLS Web Server Authentication
Some of this may not be enforced in currently shipping fetchmail
versions, but since a lot of public foot-shooting was involved in
third-party documentation that advised trust-on-first-use schemes
without warning people of the dangers involved, future versions might
actually tighten things even more, so, f.i. validate CA flags of all but
the server certificate.
I don't currently use Debian or derivatives as so you need to check
[update-]ca-certificates documentation and configuration to be sure that
your certificate is (a) put in the right place where
update-ca-certificate finds it, (b) "enabled" in configuration and
processed into the output trust store, and (c) not in a place where it
will be removed on system upgrades. dpkg-reconfigure ca-certificates -
possibly with some modified priority option - might be required.
That stackexchange link in the earlier message hints that there were
changes somewhen in the past, and also be sure to re-check documentation
since the answer there is older than Debian 11.
No, where does that access happen? The trust store is local to your
computer and fetchmail might use your system's DNS resolver (which can
have privacy implications) and will connect to the servers you point it to.
First you send your certificate to the public CA to sign it.
Then an client must connect the CA to proove that the public certificate is
correct signed.
Correct or wrong?
If I am my own CA, I am not sending something anywhere. I install the ca
certificate on my clients' trust stores, put its (the CA) private keys
on a CD or USB key so it's not left on my computer (let alone on my
server), and that's it. I've been doing that for more than a dozen
years; for public services however Let's Encrypt is a viable alternative.
