Allow ownca provider to not copy all, or overwrite specific data from the CSR

[felixfontein]

SUMMARY

This was suggested as part of #76.

ISSUE TYPE

• Feature Idea

COMPONENT NAME

x509_certificate, ownca provider

[MarkusTeufelberger]

From the initial issue:

"[This] might still be a useful feature if you expect to handle CSRs coming from users with all kinds of garbage inside. I'm unsure if there's a way to kinda re-package a CSR (e.g. you get a weird one: create one with proper settings using Ansible instead, plop in the public key of the weird one and just don't sign it, then create a certificate from it ignoring the missing/invalid signature) that might be a bit more feasible than adding nearly all CSR fields to ownca as well..."

This is not how I personally use ownca, but it could be a feature that would be necessary for someone operating a CA and getting user requests for certificates.

It seems like CSRs have to be signed, so a potential way forward would be to extend openssl_csr to partially/completely rewrite a CSR and intentionally create an invalid signature and extend x509_certificate to accept CSRs with invalid signatures. This way there wouldn't be a huge number of potential parameters added (almost all fields in a CSR can also be added/overwritten/ignored by a CA).

[felixfontein]

It seems like CSRs have to be signed, so a potential way forward would be to extend openssl_csr to partially/completely rewrite a CSR and intentionally create an invalid signature and extend x509_certificate to accept CSRs with invalid signatures. This way there wouldn't be a huge number of potential parameters added (almost all fields in a CSR can also be added/overwritten/ignored by a CA).

I'm a bit scared of this; I'm afraid that if cryptography allows to do this right now, it will eventually stop allowing that and then we're screwed (resp. have to invest a lot of work to re-create it somehow else :) ).

[felixfontein]

Another idea: allow to white-list extensions that are copied over (by default: all), and allow to specify Base64 encoded content of extensions to be added. Then we could have another module which can generate encoded extensions. (You can of course also use openssl_csr_pipe to create a CSR with a random key and the extensions your want, and use openssl_csr_info to extract the extension Base64 from that CSR to pass in into ownca.) Maybe that would be a rather small amount of work that already enables this.

[MarkusTeufelberger]

https://cryptography.io/en/latest/x509/reference/#cryptography.x509.CertificateSigningRequest.is_signature_valid exists and is in use e.g. in

community.crypto/plugins/module_utils/crypto/module_backends/certificate.py

Line 172 in 4ab2ed8

if not self.csr.is_signature_valid:

The likelyhood that they remove the ability to parse otherwise well-formed CSRs with invalid signatures is rather low in my opinion.

I'm not sure if it is even possible to create a certificate directly from a CSR in cryptography,

community.crypto/plugins/module_utils/crypto/module_backends/certificate_ownca.py

Line 117 in 94634a3

def generate_certificate(self):

at least just copies over the fields from module parameters and a parsed CSR object "manually".

[felixfontein]

The likelyhood that they remove the ability to parse otherwise well-formed CSRs with invalid signatures is rather low in my opinion.

I'm not talking about reading well-formed CSRs with invalid signatures, but creating such CSRs. After all you proposed to create a module which allows to create such CSRs :)

I'm not sure if it is even possible to create a certificate directly from a CSR in cryptography,

It is not. The standard way is copying over what's needed, as we do right now. A CSR is mainly a signed container for public key + extensions + some additional data.