[Kea-users] kea-2.2.0 - HA cluster - communication between stork and dhcp4 gets lost

[Eric Graham]

Stefan,

Sounds good! That should be all... I'd just test by first trying a simple cURL to the control agent, maybe. It shouldn't complain about an unknown cert; if it does, then there's clearly an issue. I also ran into issues where, for some unknown reason, my certificates weren't validating against the CA... so checking that is maybe worth it, if the cURL test fails. But if that was the case, I'd expect heartbeats between the two servers to be failing as well.

Good luck to you with your changes. 🙂

Eric Graham
DevOps Specialist
Direct: 605.990.1859
Eric.Graham at vantagepnt.com<mailto:eric.graham at vantagepnt.com>
[cid:644cffd4-1051-44e1-91fc-5e4271301454]
________________________________
From: Stefan G. Weichinger <lists at xunil.at>
Sent: Friday, June 30, 2023 11:23 AM
To: Eric Graham <eric.graham at vantagepnt.com>; kea-users at lists.isc.org <kea-users at lists.isc.org>
Subject: Re: [Kea-users] kea-2.2.0 - HA cluster - communication between stork and dhcp4 gets lost

CAUTION: This email originated outside the organization. Do not click any links or attachments unless you have verified the sender.

Am 30.06.23 um 17:53 schrieb Eric Graham:
> Stefan,
>
> I've been down this road and the short answer is to not bother trying to
> use the various options to skip certificate verification. Those settings
> don't do what you (I) think they do, and it's easier to just make the
> certs work.
>
> When you generate the certificates under your CA, add the IP address of
> each server as an IP SAN. For example, given a key, CA, and CSR, this is
> how I make a certificate:
>
> *HOSTNAME='1.2.3.4'*
> *openssl x509 -req -sha512 -days 365 -in ${HOSTNAME}.csr -CA ca.crt
> -CAkey cakey.pem -CAcreateserial -out ${HOSTNAME}.crt -extensions SAN
> -extfile <(printf "[SAN]\nsubjectAltName=IP:${HOSTNAME}")*
> *
> *
> In my case, I only care to make the certificate work for IP address, so
> you'll need to adjust the various options (obviously). When you're done,
> use the *-print* option to openssl on *${HOSTNAME}.crt* to double check
> that the SAN is added.
>
> Then, double-double check that the CA is imported on both Kea servers,
> the Stork server, and since you mentioned Docker - also inside any
> containerized version of the aforementioned.
>
> Again, I don't change any of the verification settings, nor any of the
> certificates except the ones that I created for Kea to use. Hope this helps.

Thanks for pointing this out. My certs were done like:

openssl req -nodes -newkey rsa:2048 -keyout server_adc1.key -out
server_adc1.csr -subj
"/C=some/ST=some/L=there/O=ISC-Kea/OU=adc1/CN=adc1/emailAddress=adr at my.tld"

so I have no IP SAN, right (grepped that command from a gist on github
and modified it).

I wanted to get it right with FQDNs in there etc ...

I will give your approach a try next week or so, currently on the train
and not touching anything anymore today.

How to double-double-check the CA import? I added it to
/usr/local/share/ca-certificates/ and ran update-ca-certificates , so
the ca.crt should be in the system's keystore.

Is that enough to make stork trust it?

I assume so as I didn't find a specific setting/variable to define a TLS
CA for the stork-agent.

So it's very likely that adding that IP SAN to the cert fixes things.

I will see next week ;-)

Thanks, have a nice weekend.
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20230630/f18b00bd/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-qwq4gcmw.png
Type: image/png
Size: 16388 bytes
Desc: Outlook-qwq4gcmw.png
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20230630/f18b00bd/attachment-0001.png>