Add openssl_certificate_info module

[felixfontein]

SUMMARY

Adds a new module openssl_certificate_info. Useful for doing most checks from #54635 / openssl_certificate's assertonly provider directly with in Ansible with register/assert.

ISSUE TYPE

• New Module Pull Request

COMPONENT NAME

openssl_certificate_info

[ansibot]

cc @MarkusTeufelberger @Shaps @Spredzy @Xyon @puiterwijk @resmo
click here for bot help

[MarkusTeufelberger]

I'd still offer the validation parameters in here eventually, assert is not really nice to use once you have moderately complex structures and its outputs are both too large and too small (An assertion failed is too little and calling assert with a loop prints EVERY item in full).

[felixfontein]

BTW, assert got a quiet parameter for Ansible 2.8, which reduces the noise a lot :) (docs) Also, when an assertion fails, the first condition which failed is printed (I think that's not new for 2.8), so there's usually enough information available.

I'm not really sure about the validation parameters; they feel wrong in an _info module for me. I have to think some more about this...

[MarkusTeufelberger]

"A slightly complex subject object I give to the module is identical to the subject of an x509 certificate" is information that I would consider valuable knowing about a certificate.

A bigger question in case of a difference is if the module result should be failed (probably not, got vetoed in the core meeting), changed (similar to running modules in check_mode?) or OK (but it was different and that's NOT ok?).

[felixfontein]

Instead of passing the subject into the _info module, you could also check it in an assert elegantly:

- name: Check certificate subject
  assert:
    that:
      - result.subject == expected_subject
  vars:
    expected_subject:
      commonName: www.ansible.com
      country: us

About the return value: _info modules should pass unchanged in general. (If they can't receive the information they need, they can fail, for example if they can't read or parse the certificate.) So if you want to return something like that, you need to add it as a return variable.

But for most conditions of current assertonly, they can be checked rather elegantly similar to the above assert. So I'm not really convinced that the _info module should have such checks.

(I added the valid_at option mainly because there is currently no way in Ansible to handle time comparisons in a good way.)

[MarkusTeufelberger]

#29951 would likely also need a special option here, right? As well as checking if a given private key fits to a certain certificate.

[felixfontein]

#29951 would likely also need a special option here, right?

If we decide that this module should be able to do that, yes. But that won't happen before stable-2.8 is branched.

As well as checking if a given private key fits to a certain certificate.

That would already be possible if there is a corresponding openssl_privatekey_info module. Just get infos on both private key and certificate, and compare public keys.

[MarkusTeufelberger]

Maybe add an empty line above this one and give it a name, it seems like the assert task is just a parameter of the openssl_certificate_info one.

[felixfontein]

I've extended the examples a bit. Can you check again?

[MarkusTeufelberger]

(you might want to change/fix the title of this PR by the way)

I mostly went through the docs, not deeply into the code so far. Great work as always, I'm starting to warm up more and more to the idea of rewriting my role(s) to use a second assert task in the future. Should this module still get merged into 2.8 (+ a deprecation notice in openssl_certificate for at least assertonly and maybe even pyOpenSSL) or are you targeting 2.9?

[felixfontein]

(you might want to change/fix the title of this PR by the way)

Thanks! Fixed it (also in the description). I also noticed I forgot to check in the tests... I hope they pass as they do on my machine ;-)

I mostly went through the docs, not deeply into the code so far. Great work as always, I'm starting to warm up more and more to the idea of rewriting my role(s) to use a second assert task in the future. Should this module still get merged into 2.8 (+ a deprecation notice in openssl_certificate for at least assertonly and maybe even pyOpenSSL) or are you targeting 2.9?

I'm currently aiming at 2.8. I'm not sure whether I want to add the deprecation notice for assertonly already, I think it's better to spend some more time thinking on whether there's a better way. In particular, having at least some of the _info modules around already for 2.8 is definitely a good thing IMO, independently of assertonly.

[felixfontein]

(Also, core freeze finally happened and feature freeze will be on April 11th, so there isn't that much time left :) )

[MarkusTeufelberger]

Yeah, that's why I was asking. ;-)

[MarkusTeufelberger]

Probably needs a changelog entry?

[felixfontein]

New modules don't need one, changelog entries are autogenerated for new modules. (source)

[MarkusTeufelberger]

shouldn't that fail CSR/Cert number 2 later, since it was issued for the private key with a password?

[ffdybuster]

The private key isn't used/needed for retrieving information on certificates.

(What's interesting though is that creating the self-signed certificate works with the wrong key... But that's unrelated to this PR...)

[MarkusTeufelberger]

So this would only be discovered if there's also an openssl_privatekey_info task and then the public keys of the subject, issuer and private key need to match up?

[felixfontein]

Passphrases are only discovered when private keys protected with passphrases are loaded, it doesn't matter by whom.

Does the cert actually contain the public key of the issuer? I thougt there's only the signature, which can be validated given the public key of the issuer (which has to be taken fom the issuer's cert, or from another source).

[MarkusTeufelberger]

https://www.alvestrand.no/objectid/2.5.29.35.html exists, but that's not set in many cases. We'd need #29951 for that.

[felixfontein]

There's also a feature request for that: #50782

But that doesn't store the public key, only some kind of hash, so you still need to get the public key from somewhere else :)

[MarkusTeufelberger]

Urgh, sometimes x509 really feels like they want to make it as hard as possible to varify/validate information... :-/

So in this case (selfsigned) only Issuer == Subject can be checked currently and the matching public key check once the openssl_privatekey_info module is here...

[felixfontein]

The aim is also to make the cert small, so you can't insert everything ;) If the objectID extension is there, you can also check if the cert's public key matches it.

Anyway, it might make sense to have another module which does some more validation, or have some more parameters to allow more complex information retrieval. But I wouldn't do that for 2.8, since we have to look at it in some more detail to find a really good solution ;)

[MarkusTeufelberger]

One feature that's now missing a bit (but not really critical, since it is likely that this module will be used in tandem with openssl_certificate) is the file permissions stuff (user/group/mode...). I wouldn't see that as a blocker though and this can be fixed later, if it is really seen as necessary.

Not much more from my side on this, having an info module that exposes everything in a cert seems generally useful.

shipit

[felixfontein]

One could argue that people should use the stat module if they want to be sure that file permissions are correct ;) A case where it is more useful is probably the openssl_privatekey_info module (because certs are usually not sensitive, while private keys are), though I'd also leave that out for now.

[MarkusTeufelberger]

(stat really should be aliased to file_info btw.)

[felixfontein]

@MarkusTeufelberger you're right! Also, thanks for reviewing!
@gundalow thanks for merging!