Docs: External CA/PKI: clarify intermediate CA cross-signing options #10392
Conversation
Al2Klimov
added
area/distributed
doc/06-distributed-monitoring.md
Outdated
| ##### Using external intermediate CA as Icinga root CA | ||
|
|
||
| For Icinga to trust only its own CA, if the latter shall be an intermediate one, | ||
| do either of the following, depending on how strict your company policy is: | ||
|
|
||
| ###### Lax policy, Icinga itself issues leave certificates | ||
|
|
||
| 1. Setup Icinga as usual, with its own CA issueing leave certificates | ||
| 2. Cross-sign that CA with the desired parent CA, so that you get an intermediate CA | ||
| with the same subject and public key as the Icinga-own root CA | ||
| 3. Add that new intermediate CA to your trusted root CAs whereever possible and needed | ||
| to have an uninterrupted chain from your company CA to Icinga leave certificates | ||
|
|
||
| ###### Strict policy, Icinga doesn't issue leave certificates | ||
|
|
||
| 1. Create your intermediate CA for Icinga | ||
| 2. Cross-sign it with itself, so that you get two equal certificates, | ||
| except that one is self-signed | ||
| 3. Use the latter as Icinga root CA and deploy leave certificates manually, | ||
| each with the intermediate CA as described in the parent section |
There was a problem hiding this comment.
@mkayontour had some questions on this section. While answering, I thought of an option to suggest, but then realized it's not documented yet.😅 So before I explained it in 🇩🇪, I thought let's just write it down in 🇬🇧 here:
doc/06-distributed-monitoring.md
Outdated
| For Icinga to trust only its own CA, if the latter shall be an intermediate one, | ||
| do either of the following, depending on how strict your company policy is: |
There was a problem hiding this comment.
What should this paragraph say? Sorry for the blunt words, but I am confused reading this.
For Icinga to trust only its own CA, if the latter shall be an intermediate one,
Doesn't Icinga always has to trust its own CA? And isn't this whole chapter about intermediate CAs?
If I get the general gist right, how about something like:
In order to use an intermediate CA with Icinga, you can do one of the following, depending on the policies you have in place.
There was a problem hiding this comment.
If you have Root -> Int1 -> Leaf, in a sane setup, you'd probably just use Root as Icinga Root CA. But then Icinga trusts Intn. Some people want Icinga to trust only Int1, e.g #7719 (comment). But, as already in our docs, OpenSSL doesn't support an intermediate CA as root one, so you have to cross-sign.
But you can do latter in two directions, this is what I'm clarifying here.
doc/06-distributed-monitoring.md
Outdated
| 1. Create your intermediate CA for Icinga | ||
| 2. Cross-sign it with itself, so that you get two equal certificates, | ||
| except that one is self-signed | ||
| 3. Use the latter as Icinga root CA and deploy leave certificates manually, | ||
| each with the intermediate CA as described in the parent section |
There was a problem hiding this comment.
Please end each sentence with a period and change leave to leaf, as I have suggested above.
Furthermore, this route needs a bit more details, imo. First, how should the intermediate CA be created? Then, unless I am mistaken, how can a CA cross-sign itself? Isn't this self-signing? When referring to "the latter" in your third statement, do you mean the signed one? Please name it.
There was a problem hiding this comment.
I'll have a look.
First, how should the intermediate CA be created?
- We already decided in Doc: Distributed Monitoring: add section "External CA/PKI" #9825 not to train people to do this
There was a problem hiding this comment.
IMHO, this still has very high "draw the rest of the owl" energy.
|
ref/NC/842002 |
Al2Klimov
force-pushed
the
Al2Klimov-patch-8
branch
from
e4c5215 to
8846465
Compare
There was a problem hiding this comment.
IMO, this whole section is still a very high-level description that is so abstract that I think it is questionable if it helps anyone. All the steps are descriptive and assume a lot of prior knowledge. Without further pointers, this may only confuse potential users who don't know how to do this, while the few with enough arcane OpenSSL knowledge won't need this information at all.
| For Icinga to trust only its own intermediate CA, | ||
| do either of the following: | ||
|
|
||
| ###### Icinga itself issues leaf certificates |
There was a problem hiding this comment.
| ###### Icinga itself issues leaf certificates | |
| ###### Leaf certificates are issued by Icinga |
To match the passive tone of the other headline below.
There was a problem hiding this comment.
Feel free to press "Commit suggestion" and trigger GHA once everything else is ✅.
This assumes Icinga "just does OpenSSL things" which is not entirely true. Examples:
We aren't as simple as e.g nginx. And even stuff like Postgres/OpenSMTPd have requirements beyond standard X.509:
So yes, software in general should note somewhere in the manual what it can do and what you may do manually without accidentally setting it on fire.
Well, at this point you're already in the very last advanced subsection beyond a disclaimer (added in #9825). 🤷♂️
... and they SHOULD not do this. :-) But if their employer forces them to do so, we clearly describe what Icinga does by itself and what's up to you. "up to you" as in "don't even contact sales". |
No description provided.