[prev in list] [next in list] [prev in thread] [next in thread] 

List:       shibboleth-users
Subject:    Re: empty certificatekeystorepassword for tomcat TLS ?
From:       Peter Schober via users <users () shibboleth ! net>
Date:       2024-04-26 9:12:36
Message-ID: ZitwBMdJyR6otN7s () aco ! net
[Download RAW message or body]

IAM David Bantz via users <users@shibboleth.net> [2024-04-25 23:12 CEST]:
> This year our server team requested a certificate for the IdP with
> an empty password.
[...]
> Should I request a newer certificate with non-null password?

The certificate knows nothing about passphrases, it's the matching
private key that may or may not be protected/encrypted with a passphrase.

That also means you can change the protection of your private key
without changing the (or requesting a new) certificate.

> What risk, if any, does that pose?

With an encrypted private key the software needs to be able to decrypt
it in order for the service to start (d'oh).  Traditionally that meant
that such a service either wasn't reboot-safe (i.e., the service
wouldn't start until an operator interactively entered a passphrase
during startup) or that the passphrase was supplied to the software as
part of its configuration (i.e., the passphrase sits around -- usually
verbatim, and only proteced by file system permissions -- in some
config file).
  The former is of course a major nuisance for operating and managing
services which requires frequent application of updates and restarting
of services, possibly unattended.
  Whether the latter actually improves security is an open question:
An attacker able to read the private key (readable by the service
account for the service, in most cases[1]) necessarily will also be
able to read the passphrase for the encrypted private key from a
configuration file that's readable by the service account.

Somewhat less traditionally there can be more abstractions added,
e.g. running services in containers and dynamically feeding the
password -- or the key material itself -- into the container. That
moves the question of the security of your key material to the
infrastructure your container runs in and to the tooling used to
store/inject the key material or passphrase.

The next step would be standing up and runing a whole infrastructure
to make services request their secrets in real time. Hashicorp Vault
is probably the most well-known of these.
And of course there's now a whole slew of services that come with
keywords such as "cloud-native", such as Akeyless.

HTH,
-peter

[1] An exception are services that start as root user (in order to
open priviledged ports, read privileged key material or config files
from disk, etc.) and then drop these rights to run the service as an
unpriviledges system account, e.g. Apache httpd is commonly run that
way.
-- 
For Consortium Member technical support, see https://shibboleth.atlassian.net/wiki/x/ZYEpPw
To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net
[prev in list] [next in list] [prev in thread] [next in thread]