GetCertificateCN(): if the CN is missing, fall back to the DNS SAN #9889
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
if exactly one is given and use it as CN.
Currently Icinga 2 populates both the DNS SAN and the subject CN of a newly issued certificate with the endpoint name. But the CN is limited to 64 characters. So endpoint names are. The only clean solution is omitting the CN for too long names. Icinga 2 must be able to extract the endpoint name from such certificates in the first place and exactly one DNS SAN is a legit source.
refs #9310
This effectively only changes the behaviour of GetCertificateCN() which has the de-facto monopoly for CN inquiry. There's also GetX509NameCN() which is additionally used in CreateCert(). But this construction area isn't about certificate issuance, see the plan.
TODO
This is the plan
Clusters with same version
obviously work. The only noteworthy are v2.16 ones as they issue new-kind certificates, but all peers already understand them since v2.15.0.
Mixed clusters as we support them
are the interesting ones and reason this complicated plan at all.
v2.15 master + v2.14 satellite + v2.13 agent
The masters only start to understand something which doesn't actually exist, yet.
v2.16 master + v2.15 satellite + v2.14 agent
Every node creates a self-signed certificate before asking its parent for an actual one. This prevents -the most important- the satellite from having a new-kind certificate the agent wouldn't recognise. Due to the fact that it still populates the CN which is limited. Not to mention the agent itself.