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.gra...@vantagepnt.com<mailto:eric.gra...@vantagepnt.com> [cid:644cffd4-1051-44e1-91fc-5e4271301454] ________________________________ From: Stefan G. Weichinger <li...@xunil.at> Sent: Friday, June 30, 2023 11:23 AM To: Eric Graham <eric.gra...@vantagepnt.com>; kea-users@lists.isc.org <kea-users@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=a...@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
-- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
