openssl_*: private key handling with passphrases?

[felixfontein]

SUMMARY

This is not really a bug, but a discussion ticket, to continue the discussion started in #53489.

In that PR, the behavior for the PyOpenSSL backends was changed so that they behave similarly to the cryptography backends (for modules having both): namely, private keys loaded with no passphrase will fail if they are encrypted (before: module would hang because PyOpenSSL would wait for user to enter passphrase), and unencrypted private keys loaded with a passphrase will also fail. The former change is clearly a bugfix, but how the latter should behave is debatable.

This change is necessary to achieve proper idempotence checks for openssl_privatekey. Here everything's fine.

For the other modules, though, they will now fail if you try to load a private key and specify a passphrase, even though the key is unencrypted. Do we want this? Or should the modules ignore this? (This new behavior was already the case for the cryptography backend for openssl_csr. cryptography fails by default if you specify a passphrase and it is not needed.)

@Spredzy @MarkusTeufelberger (or anybody else interested): what do you think?

ISSUE TYPE

• Bug Report

COMPONENT NAME

openssl_privatekey
openssl_csr
openssl_certificate
openssl_publickey
openssl_pkcs12

ANSIBLE VERSION

2.8.0

[ansibot]

Files identified in the description:

• lib/ansible/modules/crypto/openssl_certificate.py
• lib/ansible/modules/crypto/openssl_csr.py
• lib/ansible/modules/crypto/openssl_pkcs12.py
• lib/ansible/modules/crypto/openssl_privatekey.py
• lib/ansible/modules/crypto/openssl_publickey.py

If these files are inaccurate, please update the component name section of the description or use the !component bot command.

click here for bot help

[ansibot]

cc @Shaps @Xyon @gdelpierre @puiterwijk @resmo
click here for bot help

[MarkusTeufelberger]

If a user specifies a passphrase, but the key is encrypted with a different one (which includes a null cipher and no passphrase - meaning cleartext) failing the execution is the sensible thing to do in every module other than openssl_privatekey (which should just generate a new key) in my opinion.

After all, someone is trying to access a resource that is not in the expected state and the module has no way to rectify this. Yes, we could try to automatically guess what else might be intended (in other contexts one might try http and https or connecting via IPv4 and v6 or TCP and UDP), but that's always just guesswork. If a private key is expected to be encrypted and it isn't, that's something that should raise some flags and not silently get ignored in the background.

[felixfontein]

We discussed this point and the questions raised in #36738 today in IRC (mostly with @Spredzy and @Shaps). We eventually agreed on the following:

• if module input cannot be read (because key passphrase is wrong, file is not readable, file is empty, ...), regenerate;
• provide backup options for all modules (default is no);
• add "big fat warning" to documentation of private key generating modules that they can overwrite existing keys, and users should use backup: yes if they want to avoid loosing their keys because of this;
• trying to open an unencrypted private key with a passphrase should fail (this was discussed via email, not in IRC), i.e. behavior should be as cryptography;
• modules should only overwrite existing file if they successfully created a new object (in case they don't; note that this will be ensured by openssl_*: proper mode support #54085).

[felixfontein]

resolved_by_pr #54294

(Everything else needed has already been merged.)

[felixfontein]

That's merged now.

close_me