Icinga
Support non-external ECC certificates
Story
The default certificate signature algorithm uses RSA. Support for ECC has been asked for. https://www.thesslstore.com/blog/explaining-ssl-handshake/#rsa-vs-diffie-hellmanecc-a-quick-history
This involves the following changes:
- Support both RSA and ECC certificates during TLS handshake
- Create CA & client certificates with ECC by default
- Create CSRs with ECC by default
- Sign CSRs with ECC
Older certificates with RSA must still work.
~ref/IP/12111~
Tasks
- [x] PoC PR #7322
- [ ] Blockers:
- [x] RHEL7 Clients #7247
- [ ] Windows Agent - C++ #7386 C#: https://github.com/Icinga/icinga2/issues/7323#issuecomment-516827176
- [ ] Verify other supported platforms
- [ ] Either patch old clients or wait for EOL
Cipher Suites
The TLS handshake signing also enforces preferring specific cipher suites then.
ECDHE-ECDSA-AES256-GCM-SHA384for new masters with new CA, certificates, new satellites/agentsECDHE-RSA-AES256-GCM-SHA384preferred for old 2.10 client RSA key pairs, signed by newer masters with ECC.
The new default preferred cipher with RSA key pairs in 2.11 will be ECDHE-RSA-AES256-GCM-SHA384 unless the clients don't support it.
PoC Patch
Extracted from #5555.
Master (new CA, certs, ECC)
$ sslscan localhost:5665
Version: 1.11.13-static
OpenSSL 1.0.2f 28 Jan 2016
Connected to ::1
Testing SSL server localhost on port 5665 using SNI name localhost
TLS Fallback SCSV:
Server supports TLS Fallback SCSV
TLS renegotiation:
Session renegotiation not supported
TLS Compression:
Compression disabled
Heartbleed:
TLS 1.2 not vulnerable to heartbleed
TLS 1.1 not vulnerable to heartbleed
TLS 1.0 not vulnerable to heartbleed
Supported Server Cipher(s):
Preferred TLSv1.2 256 bits ECDHE-ECDSA-AES256-GCM-SHA384 Curve P-384 DHE 384
Accepted TLSv1.2 128 bits ECDHE-ECDSA-AES128-GCM-SHA256 Curve P-384 DHE 384
Accepted TLSv1.2 256 bits ECDHE-ECDSA-AES256-SHA384 Curve P-384 DHE 384
Accepted TLSv1.2 128 bits ECDHE-ECDSA-AES128-SHA256 Curve P-384 DHE 384
SSL Certificate:
Signature Algorithm: ecdsa-with-SHA256
Subject: mbpmif.int.netways.de
Altnames: DNS:mbpmif.int.netways.de
Issuer: Icinga CA
Not valid before: Jul 15 14:16:00 2019 GMT
Not valid after: Jul 11 14:16:00 2034 GMT
Working Clients
Debian Buster has ECC available by default. After signing the new certificates, a connect works with the new hardened cipher list.
$ sslscan 192.168.33.22:5665
Version: 1.11.13-static
OpenSSL 1.0.2f 28 Jan 2016
Connected to 192.168.33.22
Testing SSL server 192.168.33.22 on port 5665 using SNI name 192.168.33.22
TLS Fallback SCSV:
Server supports TLS Fallback SCSV
TLS renegotiation:
Session renegotiation not supported
TLS Compression:
Compression disabled
Heartbleed:
TLS 1.2 not vulnerable to heartbleed
TLS 1.1 not vulnerable to heartbleed
TLS 1.0 not vulnerable to heartbleed
Supported Server Cipher(s):
Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve P-256 DHE 256
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve P-256 DHE 256
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA384 Curve P-256 DHE 256
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA256 Curve P-256 DHE 256
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA Curve P-256 DHE 256
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA Curve P-256 DHE 256
Accepted TLSv1.2 256 bits AES256-GCM-SHA384
Accepted TLSv1.2 128 bits AES128-GCM-SHA256
Accepted TLSv1.2 256 bits AES256-SHA256
Accepted TLSv1.2 128 bits AES128-SHA256
Accepted TLSv1.2 256 bits AES256-SHA
Accepted TLSv1.2 256 bits CAMELLIA256-SHA
Accepted TLSv1.2 128 bits AES128-SHA
Accepted TLSv1.2 128 bits CAMELLIA128-SHA
SSL Certificate:
Signature Algorithm: ecdsa-with-SHA256
RSA Key Strength: 4096
Subject: icinga2-debian10.vagrant.demo.icinga.com
Altnames: DNS:icinga2-debian10.vagrant.demo.icinga.com
Issuer: Icinga CA
Not valid before: Jul 15 14:55:55 2019 GMT
Not valid after: Jul 11 14:55:55 2034 GMT
v2.10.5
[2019-07-15 16:56:03 +0200] information/JsonRpcConnection: Received certificate request for CN 'icinga2-debian10.vagrant.demo.icinga.com' not signed by our CA.
[2019-07-15 16:56:03 +0200] information/JsonRpcConnection: Sending certificate response for CN 'icinga2-debian10.vagrant.demo.icinga.com' to endpoint 'icinga2-debian10.vagrant.demo.icinga.com'.
[2019-07-15 16:56:03 +0200] warning/JsonRpcConnection: API client disconnected for identity 'icinga2-debian10.vagrant.demo.icinga.com'
019-07-15 16:56:06 +0200] information/JsonRpcConnection: Received certificate request for CN 'icinga2-debian10.vagrant.demo.icinga.com' signed by our CA.
[2019-07-15 16:56:06 +0200] information/JsonRpcConnection: The certificate for CN 'icinga2-debian10.vagrant.demo.icinga.com' is valid and uptodate. Skipping automated renewal.
Non-Working Clients
RHEL7 based platforms do not load the ECC cipher suite by default. This results in no shared cipher errors when hardening the cipher lists.
v2.10.5 offers the following cipher list, once the CSR is signed with elliptic curve signature algorithm:
$ sslscan 192.168.33.5:5665
Version: 1.11.13-static
OpenSSL 1.0.2f 28 Jan 2016
Connected to 192.168.33.5
Testing SSL server 192.168.33.5 on port 5665 using SNI name 192.168.33.5
TLS Fallback SCSV:
Server supports TLS Fallback SCSV
TLS renegotiation:
Secure session renegotiation supported
TLS Compression:
Compression disabled
Heartbleed:
TLS 1.2 not vulnerable to heartbleed
TLS 1.1 not vulnerable to heartbleed
TLS 1.0 not vulnerable to heartbleed
Supported Server Cipher(s):
Preferred TLSv1.2 256 bits AES256-GCM-SHA384
Accepted TLSv1.2 256 bits AES256-SHA256
Accepted TLSv1.2 256 bits AES256-SHA
Accepted TLSv1.2 256 bits CAMELLIA256-SHA
Accepted TLSv1.2 128 bits AES128-GCM-SHA256
Accepted TLSv1.2 128 bits AES128-SHA256
Accepted TLSv1.2 128 bits AES128-SHA
Accepted TLSv1.2 128 bits CAMELLIA128-SHA
Preferred TLSv1.1 256 bits AES256-SHA
Accepted TLSv1.1 256 bits CAMELLIA256-SHA
Accepted TLSv1.1 128 bits AES128-SHA
Accepted TLSv1.1 128 bits CAMELLIA128-SHA
Preferred TLSv1.0 256 bits AES256-SHA
Accepted TLSv1.0 256 bits CAMELLIA256-SHA
Accepted TLSv1.0 128 bits AES128-SHA
Accepted TLSv1.0 128 bits CAMELLIA128-SHA
SSL Certificate:
Signature Algorithm: ecdsa-with-SHA256
RSA Key Strength: 4096
Subject: icinga2.vagrant.demo.icinga.com
Altnames: DNS:icinga2.vagrant.demo.icinga.com
Issuer: Icinga CA
Not valid before: Jul 15 14:28:17 2019 GMT
Not valid after: Jul 11 14:28:17 2034 GMT
In order to fix this, a new icinga2 binary release is required with backporting #7247 to all our supported client platforms.
PoC Tests
Certificates
michi@Michaels-MacBook-Pro /usr/local/icinga/icinga2/var/lib/icinga2 $ openssl x509 -in ca/ca.crt -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
b7:3c:0a:fe:9c:39:f4:8c:6c:12:a3:7d:9b:f9:0c:b7:4e:14:fd:24
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=Icinga CA
Validity
Not Before: Jul 15 14:16:00 2019 GMT
Not After : Jul 11 14:16:00 2034 GMT
Subject: CN=Icinga CA
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
michi@Michaels-MacBook-Pro /usr/local/icinga/icinga2/var/lib/icinga2 $ openssl x509 -in certs/mbpmif.int.netways.de.crt -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
e2:1e:6b:91:18:c2:53:1d:da:8a:18:3b:e0:fe:b9:75:74:80:e4:64
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=Icinga CA
Validity
Not Before: Jul 15 14:16:00 2019 GMT
Not After : Jul 11 14:16:00 2034 GMT
Subject: CN=mbpmif.int.netways.de
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
$ openssl s_client -connect localhost:5665
---
SSL handshake has read 1433 bytes and written 370 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384
Server public key is 384 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-ECDSA-AES256-GCM-SHA384
Signing Request from 2.10 Client
- node wizard on the Client, without ticket
- ca list on the 2.11 master
michi@Michaels-MacBook-Pro ~/dev/testing $ icinga2 ca list
Fingerprint | Timestamp | Signed | Subject
-----------------------------------------------------------------|--------------------------|--------|--------
bdb0f1d049da82eaab0c2e7cf624d37efe4d3018528024b4bf6223b3864b1e24 | Jul 15 14:13:36 2019 GMT | | CN = icinga2.vagrant.demo.icinga.com
- Extract the CSR from /var/lib/icinga2/certificate-requests, reformat it a bit from JSON.
- Verify the signature algorithm
michi@Michaels-MacBook-Pro ~/dev/testing $ openssl x509 -in certreq-edsca -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
06:69:5f:a3:aa:d3:4c:95:7c:ba:ee:d2:c6:26:86:8e:95:00:df:0d
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=icinga2.vagrant.demo.icinga.com
Validity
Not Before: Jul 15 14:13:36 2019 GMT
Not After : Jul 11 14:13:36 2034 GMT
Subject: CN=icinga2.vagrant.demo.icinga.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
00:c1:a5:74:28:c6:79:fd:74:21:c4:7c:4f:10:41:
62:d9:5e:b7:d8:37:fa:28:2a:8e:e8:75:2d:71:69:
d9:2e:7f:17:ef:59:e1:96:80:28:f1:3f:e6:4b:e5:
18:76:3e:e5:c8:8e:9e:e9:b5:8f:17:bd:fe:22:7f:
55:bf:f3:1b:e7:08:e1:41:da:b3:c3:2a:d5:a9:04:
20:66:22:23:f1:d6:67:df:1b:4e:be:45:4f:ff:35:
34:b1:07:d6:20:de:9d:f8:87:6c:ec:f7:d1:67:79:
c4:f9:96:60:3d:db:a9:55:78:25:9f:02:68:bc:e5:
e3:11:65:c1:28:ce:67:30:22:06:f9:46:e4:fc:e1:
5c:04:2a:a3:dc:9b:64:f5:f1:3b:35:35:66:f1:31:
b1:70:b1:77:81:67:db:05:db:dd:b0:02:b0:a0:1c:
14:d3:e8:91:aa:d6:df:27:55:2f:7f:3b:e1:8f:bc:
e8:b4:80:fc:97:39:6f:8d:00:75:5c:4e:ab:83:20:
41:9f:8f:fc:41:6f:51:88:25:55:11:5e:37:95:f2:
6c:3d:4f:ab:2f:73:4a:8f:8a:72:a6:14:85:94:16:
aa:87:3e:d1:4c:a7:aa:62:3e:fe:c4:ec:d7:d9:b7:
86:b7:3f:cc:e9:76:6a:bb:8b:05:b9:a9:e8:ee:7e:
fe:88:ef:de:bb:d4:79:71:5c:15:46:4c:15:13:6e:
78:28:ea:c9:5e:3f:52:d5:a7:5c:15:1a:72:c8:b2:
63:25:80:8f:aa:74:03:f2:a8:8c:24:79:98:e7:64:
eb:bf:7e:e2:0e:52:79:1d:ce:2f:ea:63:0a:bc:32:
c2:b5:37:4e:52:9a:35:84:47:35:6d:ae:70:eb:ad:
9d:1b:4e:31:be:63:b7:31:57:ad:d3:93:b5:5b:0c:
d3:e3:99:15:f2:da:61:59:2d:0c:bc:af:4b:05:0f:
08:13:a5:97:e8:7d:c7:9d:6e:26:80:33:2a:1d:3a:
98:5f:e3:0c:ed:f4:a4:84:57:14:b1:94:c1:62:a9:
cb:a6:49:22:94:49:63:53:c5:63:45:ff:7f:ca:35:
0f:7b:45:0c:a1:d6:66:5b:3f:ca:42:c2:d9:30:81:
1a:ab:5d:ae:01:90:93:e1:30:d2:09:ee:e0:9e:b8:
96:9c:b5:be:0c:58:ad:47:81:39:a6:f9:45:61:6f:
2c:fa:0c:43:2a:3c:18:44:4d:e9:e8:55:34:62:48:
6e:5f:77:82:d5:89:0f:80:86:7c:eb:88:2a:6d:80:
86:2b:0f:d2:02:25:0b:c0:e7:6a:15:38:98:78:d7:
98:8d:29:b8:e4:20:e6:63:1f:77:2e:92:40:ef:4f:
1b:14:19
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Alternative Name:
DNS:icinga2.vagrant.demo.icinga.com
Signature Algorithm: sha256WithRSAEncryption```
- Sign the CSR on the 2.11 master
$ icinga2 ca sign bdb0f1d049da82eaab0c2e7cf624d37efe4d3018528024b4bf6223b3864b1e24
information/cli: Signed certificate for 'CN = icinga2.vagrant.demo.icinga.com'.
- Restart the client
Fails with the single cipher suite, that's expected.
[2019-07-15 16:22:14 +0200] warning/TlsStream: OpenSSL error: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher
[2019-07-15 16:22:14 +0200] critical/ApiListener: Client TLS handshake failed (from [192.168.33.22]:48980): Error: Socket was closed during TLS handshake.
(0) Handling new API client connection
Context:
(0) Handling new API client connection
- Verify the certificates on the client
[root@icinga2 ~]# openssl x509 -in /var/lib/icinga2/certs/icinga2.vagrant.demo.icinga.com.crt -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
21:59:83:9a:42:e6:0e:f6:26:0e:e7:93:70:4b:ed:2d:8b:a2:47:3e
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=Icinga CA
Validity
Not Before: Jul 15 14:28:17 2019 GMT
Not After : Jul 11 14:28:17 2034 GMT
Subject: CN=icinga2.vagrant.demo.icinga.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
I ran into this when testing the Windows C# setup wizard with Icinga 2 running ECC certificates. I did not debug further, but once this draft becomes reality we need to ensure that our Windows Agent is fully functional with it as well.
https://stackoverflow.com/questions/32873851/load-a-certificate-using-x509certificate2-with-ecc-public-key
@pdolinic I'd like to hear you opinion on this. Do we want this? And why (not)?
Would it be nice to have? Yes. Is it mission-critical to implement it? No. Should it be taken into account if we do larger changes to the TLS/CA functionality? Absolutely.
Since I was asked for my opinion, ECC is better than RSA due to smaller keysize allowing better performance. Abstract, summary and pictures here should show this well https://www.researchgate.net/publication/322558426_RSA_and_ECC_A_comparative_analysis
- Personally? I use Wireguard and OpenVPN with ECC, because it is better :) Would I recommend that to a Client? I would let him decide. That is because newer standards have gone through good auditing especially when on low codebase, but due to low smaller adaptaion there is still not full trust on it.
- Will ECC become unavoidable in the future? Yes (not only) because IoT has mostly no dedicated hardware acceleration for cryptography and this is a huge problem currently.
I agree with both of you, but would support this in the end.
Would it be nice to have? Yes. Is it mission-critical to implement it? No. Should it be taken into account if we do larger changes to the TLS/CA functionality? Absolutely.
There are two parts to that discussion:
- Security: the debate which curved might or might not be backdoored will probably never settle, so you'll probably always find someone saying "but I want my RSA back". But all in all, ECDSA has seen quite some adoption over the last years, so it'll probably be fine. I think betting on RSA or ECC being more secure is a bet you can't win.
- Performance: Given that Icinga mostly uses long-lived connections means the cost of an individual handshake does not have a too high impact. But I think it's quite possible to see an improvement on reloads when everything reconnects at once.
Also there are multiple parts to this issue:
- Ensure that our code does not restrict what the OpenSSL version in use can handle. So that if you issue certificates yourself and your OpenSSL version supports them, Icinga will be happy. (I don't know what's the current state there.)
- Add support so that Icinga CA can issue ECC certificates.
- Decide if ECC certificates should be the default or an option or the only way Icinga issues certificates. Note that for this to work, step 1 has to be done way before so that this would work with our version support matrix.
@Al2Klimov I am not a Dev but default ECC could have unwanted consequences for lots of older devices https://support.globalsign.com/ssl/ssl-certificates-life-cycle/ecc-compatibility and this is only the first thing that came to my mind, there will be more than this.
Optional could also be a challenge, because it also depends on the weakest endpoints which means you might have to revert to default/RSA anyways. Could this cause problem for Masters and Satellites as well?
Implementing a new Crypto-Stack is probably something that is very big, has to be planned and thought out well with all the edge-cases involved. Not something to rush through.
- One last thing would be think about all of "optional" in cases of TLS1.0 vs TLS 1.3 or AES-CBC vs AES-GCM in terms of downgrade attacks.
I don't think I can contribute more to this discussion with my half-knowledge (or maybe better half of half knowledge :D), this is pretty much the end of what I know.
- the debate which curved might or might not be backdoored will probably never settle, so you'll probably always find someone saying "but I want my RSA back"
Shall we wait for https://www.rfc-editor.org/rfc/rfc8410 then?
- As of now in 2023, I'd support going ECC, due to more performance and more security. ECC SSH keys are also the way to go as a sysadmin atm.
- Question might be, customers with legacy hardware, which we always have to keep in mind.
@Al2Klimov I am not a Dev but default ECC could have unwanted consequences for lots of older devices https://support.globalsign.com/ssl/ssl-certificates-life-cycle/ecc-compatibility and this is only the first thing that came to my mind, there will be more than this.
- Question might be, customers with legacy hardware, which we always have to keep in mind.
I don't see how hardware support plays any role here. We're not talking about any checks that have to interact with spooky management interfaces of old hardware or something like that. We're talking about the use of certificates within Icinga itself. This means cluster connections (something we mostly control ourselves) and the HTTPS API (which has external users). So if at all, this is a question of software compatibility. And support for ECC definitely isn't something new. Your link states that OpenSSL supports it since 0.9.8 which was released in 2005. Probably not long until I can say that's older than some of your coworkers.
- the debate which curved might or might not be backdoored will probably never settle, so you'll probably always find someone saying "but I want my RSA back"
Shall we wait for https://www.rfc-editor.org/rfc/rfc8410 then?
Nothing that would prevent starting with the first of the three steps I outlined in https://github.com/Icinga/icinga2/issues/7323#issuecomment-936140040. In case Icinga 2.13 can't handle certificates signed with ECDSA, we couldn't switch so an ECDSA in 2.15 if we wanted to.
Security: the debate which curved might or might not be backdoored will probably never settle, so you'll probably always find someone saying "but I want my RSA back".
E.g. me. Seriously, all of my TLS and DNSSEC KSK certs are RSA x4096.
Anyway, what do you think about
- waiting for actual customer demand
- a hard opt in/out switch to be set on every(!) node
- a soft opt in/out switch which en-/disables issuing ECC in addition to RSA on the masters, the rest assimilates
According to ChatGPT you can have multiple verification roots of different key types (of course), multiple server certs, but not multiple client certs, so we'd have to try ECC and fall back to RSA.
For the record
Apropos:
waiting for actual customer demand
OP:
The default certificate signature algorithm uses RSA. Support for ECC has been asked for.
ref/IP/12111
Yes and no.
Quote from mentioned ticket:
Hi, Our customer REDACTED has a requirement to: "Enable TLS/SSL support for strong ciphers Enable support for at least one of the ciphers listed below: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384"
I emphasise: at least one. E.g. DHE-RSA-AES256-GCM-SHA384. It indeed didn't work
➜ icinga2 git:(a3dabde28) curl -fksS --tls-max 1.2 --cipher DHE-RSA-AES256-GCM-SHA384 https://127.0.0.1:5665/
curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 127.0.0.1:5665
➜ icinga2 git:(a3dabde28) curl -fksS --tls-max 1.2 https://127.0.0.1:5665/
curl: (22) The requested URL returned error: 401
➜ icinga2 git:(a3dabde28)
until v2.14
➜ icinga2 git:(master) curl -fksS --tls-max 1.2 --cipher DHE-RSA-AES256-GCM-SHA384 https://127.0.0.1:5665/
curl: (22) The requested URL returned error: 401
➜ icinga2 git:(master)
thanks to
- #9811
Btw. ECDHE-RSA-AES256-GCM-SHA384 seems to already work for me w/o the PR.
(Not to mention their both 128-conterparts.)
But this PR is unnecessary if your OpenSSL (not on RHEL 7 😅) and Icinga (since 2.13) provide TLS 1.3:
- #8718
In short, nobody actually needs ECC, the customer can sleep quietly and I can deref. the RT ticket.
For the record II
External ECC PKIs already work:
[root@aklimov-ecc-1 ~]# openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:secp521r1 -subj '/CN=Ext. Root CA' -sha1 -keyout root.key -out root.crt -nodes
-----
[root@aklimov-ecc-1 ~]# openssl req -newkey ec -pkeyopt ec_paramgen_curve:secp521r1 -subj '/CN=aklimov-ecc-1.novalocal' -keyout aklimov-ecc-1.novalocal.key -out aklimov-ecc-1.novalocal.csr -nodes
-----
[root@aklimov-ecc-1 ~]# openssl x509 -req -in aklimov-ecc-1.novalocal.csr -sha512 -out aklimov-ecc-1.novalocal.crt -CA root.crt -CAkey root.key -CAcreateserial -extensions SAN -extfile <(printf '[SAN]\nsubjectAltName=DNS:aklimov-ecc-1.novalocal')
Certificate request self-signature ok
subject=CN = aklimov-ecc-1.novalocal
[root@aklimov-ecc-1 ~]# cp aklimov-ecc-1.novalocal.* /var/lib/icinga2/certs
[root@aklimov-ecc-1 ~]# chown icinga: /var/lib/icinga2/certs/aklimov-ecc-1.novalocal.*
[root@aklimov-ecc-1 ~]# cp root.crt /var/lib/icinga2/certs/ca.crt
[root@aklimov-ecc-1 ~]# icinga2 feature enable api
Enabling feature api. Make sure to restart Icinga 2 for these changes to take effect.
[root@aklimov-ecc-1 ~]# icinga2 daemon -C
[2023-07-04 14:09:20 +0000] information/cli: Icinga application loader (version: r2.13.0-1)
[2023-07-04 14:09:20 +0000] information/cli: Loading configuration file(s).
[2023-07-04 14:09:20 +0000] information/ConfigItem: Committing config item(s).
[2023-07-04 14:09:20 +0000] information/ApiListener: My API identity: aklimov-ecc-1.novalocal
[2023-07-04 14:09:20 +0000] information/ConfigItem: Instantiated 2 NotificationCommands.
[2023-07-04 14:09:20 +0000] information/ConfigItem: Instantiated 12 Notifications.
[2023-07-04 14:09:20 +0000] information/ConfigItem: Instantiated 1 IcingaApplication.
[2023-07-04 14:09:20 +0000] information/ConfigItem: Instantiated 2 HostGroups.
[2023-07-04 14:09:20 +0000] information/ConfigItem: Instantiated 1 Host.
[2023-07-04 14:09:20 +0000] information/ConfigItem: Instantiated 3 Zones.
[2023-07-04 14:09:20 +0000] information/ConfigItem: Instantiated 1 FileLogger.
[2023-07-04 14:09:20 +0000] information/ConfigItem: Instantiated 1 CheckerComponent.
[2023-07-04 14:09:20 +0000] information/ConfigItem: Instantiated 1 Endpoint.
[2023-07-04 14:09:20 +0000] information/ConfigItem: Instantiated 1 NotificationComponent.
[2023-07-04 14:09:20 +0000] information/ConfigItem: Instantiated 1 ApiListener.
[2023-07-04 14:09:20 +0000] information/ConfigItem: Instantiated 245 CheckCommands.
[2023-07-04 14:09:20 +0000] information/ConfigItem: Instantiated 1 User.
[2023-07-04 14:09:20 +0000] information/ConfigItem: Instantiated 1 UserGroup.
[2023-07-04 14:09:20 +0000] information/ConfigItem: Instantiated 3 ServiceGroups.
[2023-07-04 14:09:20 +0000] information/ConfigItem: Instantiated 3 TimePeriods.
[2023-07-04 14:09:20 +0000] information/ConfigItem: Instantiated 11 Services.
[2023-07-04 14:09:20 +0000] information/ConfigItem: Instantiated 1 ScheduledDowntime.
[2023-07-04 14:09:20 +0000] information/ScriptGlobal: Dumping variables to file '/var/cache/icinga2/icinga2.vars'
[2023-07-04 14:09:20 +0000] information/cli: Finished validating the configuration file(s).
[root@aklimov-ecc-1 ~]#
[root@aklimov-ecc-2 ~]# openssl req -newkey ec -pkeyopt ec_paramgen_curve:secp521r1 -subj '/CN=aklimov-ecc-2.novalocal' -keyout aklimov-ecc-2.novalocal.key -out aklimov-ecc-2.novalocal.csr -nodes
-----
[root@aklimov-ecc-2 ~]#
(copies aklimov-ecc-2.novalocal.csr over)
[root@aklimov-ecc-1 ~]# openssl x509 -req -in aklimov-ecc-2.novalocal.csr -sha512 -out aklimov-ecc-2.novalocal.crt -CA root.crt -CAkey root.key -CAcreateserial -extensions SAN -extfile <(printf '[SAN]\nsubjectAltName=DNS:aklimov-ecc-2.novalocal')
Certificate request self-signature ok
subject=CN = aklimov-ecc-2.novalocal
[root@aklimov-ecc-1 ~]#
(copies aklimov-ecc-2.novalocal.crt and root.crt over)
[root@aklimov-ecc-2 ~]# cp aklimov-ecc-2.novalocal.* /var/lib/icinga2/certs
[root@aklimov-ecc-2 ~]# chown icinga: /var/lib/icinga2/certs/aklimov-ecc-2.novalocal.*
[root@aklimov-ecc-2 ~]# cp root.crt /var/lib/icinga2/certs/ca.crt
[root@aklimov-ecc-2 ~]# icinga2 feature enable api
Enabling feature api. Make sure to restart Icinga 2 for these changes to take effect.
[root@aklimov-ecc-2 ~]# icinga2 daemon -C
[2023-07-04 14:16:29 +0000] information/cli: Icinga application loader (version: r2.13.0-1)
[2023-07-04 14:16:29 +0000] information/cli: Loading configuration file(s).
[2023-07-04 14:16:29 +0000] information/ConfigItem: Committing config item(s).
[2023-07-04 14:16:29 +0000] information/ApiListener: My API identity: aklimov-ecc-2.novalocal
[2023-07-04 14:16:29 +0000] information/ConfigItem: Instantiated 2 NotificationCommands.
[2023-07-04 14:16:29 +0000] information/ConfigItem: Instantiated 12 Notifications.
[2023-07-04 14:16:29 +0000] information/ConfigItem: Instantiated 1 IcingaApplication.
[2023-07-04 14:16:29 +0000] information/ConfigItem: Instantiated 2 HostGroups.
[2023-07-04 14:16:29 +0000] information/ConfigItem: Instantiated 1 Host.
[2023-07-04 14:16:29 +0000] information/ConfigItem: Instantiated 3 Zones.
[2023-07-04 14:16:29 +0000] information/ConfigItem: Instantiated 1 FileLogger.
[2023-07-04 14:16:29 +0000] information/ConfigItem: Instantiated 1 CheckerComponent.
[2023-07-04 14:16:29 +0000] information/ConfigItem: Instantiated 1 Endpoint.
[2023-07-04 14:16:29 +0000] information/ConfigItem: Instantiated 1 NotificationComponent.
[2023-07-04 14:16:29 +0000] information/ConfigItem: Instantiated 1 ApiListener.
[2023-07-04 14:16:29 +0000] information/ConfigItem: Instantiated 245 CheckCommands.
[2023-07-04 14:16:29 +0000] information/ConfigItem: Instantiated 1 User.
[2023-07-04 14:16:29 +0000] information/ConfigItem: Instantiated 1 UserGroup.
[2023-07-04 14:16:29 +0000] information/ConfigItem: Instantiated 3 ServiceGroups.
[2023-07-04 14:16:29 +0000] information/ConfigItem: Instantiated 3 TimePeriods.
[2023-07-04 14:16:29 +0000] information/ConfigItem: Instantiated 11 Services.
[2023-07-04 14:16:29 +0000] information/ConfigItem: Instantiated 1 ScheduledDowntime.
[2023-07-04 14:16:29 +0000] information/ScriptGlobal: Dumping variables to file '/var/cache/icinga2/icinga2.vars'
[2023-07-04 14:16:29 +0000] information/cli: Finished validating the configuration file(s).
[root@aklimov-ecc-2 ~]# cat << EOF > /etc/icinga2/zones.conf
object Endpoint "aklimov-ecc-1.novalocal" {
host = "10.27.3.17"
}
object Endpoint "aklimov-ecc-2.novalocal" {
host = "10.27.1.120"
}
object Zone "master" {
endpoints = [ "aklimov-ecc-1.novalocal", "aklimov-ecc-2.novalocal" ]
}
EOF
[root@aklimov-ecc-2 ~]#
[root@aklimov-ecc-1 ~]# cat << EOF > /etc/icinga2/zones.conf
object Endpoint "aklimov-ecc-1.novalocal" {
host = "10.27.3.17"
}
object Endpoint "aklimov-ecc-2.novalocal" {
host = "10.27.1.120"
}
object Zone "master" {
endpoints = [ "aklimov-ecc-1.novalocal", "aklimov-ecc-2.novalocal" ]
}
EOF
[root@aklimov-ecc-1 ~]#
Now, if I fire up the Icingas, they recognise each other. With config acceptance enabled in the API feature they even sync config to each other.
Suggestion: Let's spare our keytype-migration time for post-quantum cryptography once it's a thing (and do nothing on ECC, yet)!