Own CA for Icinga Cluster/API communication?

cluster
certificates
tls
api

(Michael Friedrich) #1

Every now and then you may be required to answer the question on “why not use the company’s CA certificates” or “The REST API is not trusted in my browser, fix it”.

Here’s some ideas and pros and cons. Please discuss your own findings below :slight_smile:

Matter of Trust

Icinga as an application with masters, satellites and agents should be used in its own CA environment. Once you open this up by e.g. re-using the Puppet CA, you’ll end up with two applications and security layers (Icinga and Puppet) opening the trust levels.

Some environments also have the idea or requirement to re-use the company CA and open this up for any installation and application in the local (or Internet) network.

What’s your experience with that, how often does this requirement occur, how do you solve?

Own CA and certificates

Keep in mind that the ApiListener object is used for two mechanisms:

  • Cluster API with JSON-RPC messages and TLS handshakes for endpoints
  • REST API where HTTP clients/browsers may connect against

By default, the CLI wizard tools will create a custom CA with self-signed certificates. Meaning to say, when an HTTP client connects, the CA is not trusted by the root CA and as such your browser marks the website as “not trusted” when connecting via https protocol.

Own Company CA

You can use your company’s CA for example when there’s a deployment mechanism for all hosts to add them to the trusted store.

Certificate Requirements

CA

  • Version 3
  • Extensions
    • x509v3 Basic Contraints: CA:TRUE

A CA generated from the Icinga CLI commands looks like this:

$ openssl x509 -in ca.crt -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            bb:d0:6d:ad:d9:b0:d3:96:f1:c4:25:6c:d7:2d:33:e0:77:f8:bd:93
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=Icinga CA
        Validity
            Not Before: Jan  4 14:32:57 2019 GMT
            Not After : Dec 31 14:32:57 2033 GMT
        Subject: CN=Icinga CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                    00:cc:7d:ec:37:83:b9:7d:07:98:3e:53:05:3f:11:
                    .....

                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
    Signature Algorithm: sha256WithRSAEncryption
         22:0c:d6:38:ea:6a:7c:62:8a:65:a6:dd:cb:4d:d3:9c:db:87:
         .......

Signed Certificates

  • Version 3
  • Subject: CN=<FQDN>
    • This is mandatory and will be used after TLS handshake for CN == endpoint object security.
  • Extensions
    • x509v3 Basic Contraints: CA:FALSE
    • x509v3 Subject Alternative Name: DNS:<FQDN>

A signed certificate from the CLI commands and auto-signing within Icinga (CA proxy, CSR autosigning) looks like this:

openssl x509 -in mbpmif.int.netways.de.crt -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            80:5c:70:7e:cf:e5:dc:04:2c:66:1b:e6:c8:e2:1d:f9:e2:38:18:46
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=Icinga CA
        Validity
            Not Before: Jan  4 14:38:12 2019 GMT
            Not After : Dec 31 14:38:12 2033 GMT
        Subject: CN=mbpmif.int.netways.de
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                    00:da:94:48:be:b0:f5:00:73:0f:70:fb:06:d4:cd:
                    ....
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Alternative Name:
                DNS:mbpmif.int.netways.de
    Signature Algorithm: sha256WithRSAEncryption
         1d:4f:4c:5c:2c:d0:ea:8b:d9:74:5b:e9:0c:17:18:fa:fc:c8:
         ....

How do you generate/use such certificates, does it work for you?

Any parts you’d like to see improved for Icinga?

Cheers,
Michael


SSL Certificate Durations
(Thomas Widhalm) #2

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 curl which 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.