TL:DR: You can replace the CA with your own if you know, what you’re doing, but don’t do it. For your own good.
The detailed version:
From a partners support engineer point of view I want to add the following: Don’t use another CA than the one Icinga brings.
We had a lot of tickets with hard to debug problems which came down to someone messing up the certificate issueing process. While it’s technically true that you can issue your own certificates in a way Icinga can use them, it’s rather easy (and common) to create ones which might not work.
All in all you’ll have a lot of extra work to do for (almost) no other benefit than ticking off a checkbox in your policy papers. Normally there are only three kinds of connection to the API:
- other Icinga instances which play well with the internal CA
- external tools/scripts which would need the CAs certificate once and are then good to go
- users using tools like
curlwhich should be “technically-minded” enough to understand and be able to deal with certificates signed by the Icinga CA
All of them can use the Icinga CA. Normally the only benefit you get from using your companys CA is that users already have that CAs certificate imported into their browsers certificate store. This prevents your browser from showing an “insecure” warning if you visit such a site. But every user who might ever connect to Icingas API should know about certificates and that these sites are not “insecure”, they merely use a certificate issued by a CA your browser doesn’t know yet.
Sorry if I’m sounding rude but this is an issue which brought us quite some hard times debugging, comes again and again and is brought up most of the time just because someone doesn’t want to dig into the topic how certificates and CAs work.