Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GetCertificateCN(): if the CN is missing, fall back to the DNS SAN #9889

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Al2Klimov
Copy link
Member

@Al2Klimov Al2Klimov commented Oct 27, 2023

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

  • v2.14 already rejects missing or too long CNs wherever they're about to appear
  • v2.15.0 -with this PR- doesn't do anything new by itself(!), but if -hypothetically speaking- it sees a peer(!) certificate w/o CN -but with one DNS SAN- the DNS SAN counts as CN
  • v2.16.0 -with additional changes- also issues certificates w/o CNs if such would exceed the limit

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.

@Al2Klimov Al2Klimov added this to the 2.15.0 milestone Oct 27, 2023
@cla-bot cla-bot bot added the cla/signed label Oct 27, 2023
@icinga-probot icinga-probot bot added area/distributed Distributed monitoring (master, satellites, clients) area/setup Installation, systemd, sample files bug Something isn't working labels Oct 27, 2023
@Al2Klimov Al2Klimov removed this from the 2.15.0 milestone Mar 11, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/distributed Distributed monitoring (master, satellites, clients) area/setup Installation, systemd, sample files bug Something isn't working cla/signed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant