Rework certificate handling to module

[widhalmt]

Thanks for the very valuable feedback @jpmens and @bodsch !

We have a lot of tasks regarding certificate handling with Elastics own tool for CA and certificate handling. Getting them as stable and idempotent as they are now gave us a really hard time. Especially thanks to @afeefghannam89 for all the energy put into that code.

Maybe the collection could benefit from modules taking care of all the handling. Here are some ideas I caught when talking to the guys mentioned at the top:

• Having one call of a module instead of constantly runnnig multiple tasks will greatly speed up the execution of the roles
• We can have a single task, similar to the ones in community.crypto that receives all specifics of the certificate and we can just check the existing certificates within the module. e.g. passphrase, SANs, names, algorithms, expiry date . If the files fail to satisfy one we can instantly replace them by calling the provided tool on the CA host
• In some cases we could locally store a checksum over a list of parameters and just check whether this checksum is different from that on new runs. Although, with certificates it might be better to check the actual file

Some ideas to consider:

• We have a local copy of all files on the CA host. But what if that get's lost, corrupted, whatever. Do we want to recreate the files and transfer them to the target host even when it doesn't need changes because it still hase the old variant?
• Same goes for checks. We can easily check all and recreate all files on the CA host. But what if files are different on the target host? Should we check with checksums or do the check on the target host in the first place?

[danopt]

We can use the authorityKeyIdentifier extension which the Elasticstack uses in their certificates. This is useful to know if the CA has been renewed. If this extension wouldn't present, then the issuer name alone would be used to identify the issuer certificate. Since this is a hex string we can see if the client has a different one in their extension and if that is the case renew it, because the CA certificate has changed, too.

If not the certificate doesn't need to be recreated, because the target has already a valid one. This would also apply if the CA has lost the certificates of the targets.

Also, we have the serial numbers we can check on the CA and target. I'm not sure if they are useful, though.

elasticsearch-ca.p12:

    "msg": {
        ...,
        "extensions": {
            "authorityKeyIdentifier": {
                ...,
                "_values": {
                    ...,
                    "_key_identifier": "FE:5B:42:4C:F1:B1:C6:E4:55:D0:A8:89:B5:6D:D8:89:59:0B:3B:8B"
                }
            },
            ...,
            "subjectKeyIdentifier": {
                ...,
                "_values": {
                    "_digest": "FE:5B:42:4C:F1:B1:C6:E4:55:D0:A8:89:B5:6D:D8:89:59:0B:3B:8B"
                }
            }
        },
        ...,
        "serial_number": "653796755506213235044968017439580057002712727100",
        ...
    }

elasticsearch-cluster1.p12 (client):

        "extensions": {
            "authorityKeyIdentifier": {
                ...,
                "_values": {
                    ...,
                    "_key_identifier": "FE:5B:42:4C:F1:B1:C6:E4:55:D0:A8:89:B5:6D:D8:89:59:0B:3B:8B"
                }
            },
            ...,
            },
            "subjectKeyIdentifier": {
                ...,
                "_values": {
                    "_digest": "23:AA:17:8F:8C:FD:5B:B3:22:83:60:AF:0A:69:0F:4F:59:05:70:05"
                }
            }
        },
        ...,
        "serial_number": "1334384389220652102013344310955683256262307485656",
        ...
    }