Not sure what version you are running but see following links for Kea documentation around TLS, cert-required, agent and kea-shell:
cert-required - this boolean parameter allows a server to not require the client certificate. Its default value is true, which means the client certificate is required and the client must be authenticated. This flag has no meaning on the client side; the server always provides a certificate which is validated by the client. https://kea.readthedocs.io/en/kea-2.4.1/arm/security.html https://kea.readthedocs.io/en/kea-2.4.1/arm/shell.html#tls-support > On Mar 14, 2024, at 15:15, CS <cs.temp.m...@gmail.com> wrote: > > Interesting. I had assumed they were supplemental and not necessarily > conflicting (IE that the certificate provided encrypted transmission and not > necessarily authentication like a web-browser.) I was also under the guidance > of the HA required certificates, although in cursory testing at the moment > that does not appear to be true. If you are correct that "when cert-required > is set to true, you must provide a client certificate and key to > authenticate" and Micetro does not appear to have an option for > authentication via cert, then I can only proceed using un:pw. > > curl works like this (without certs) as does kea-shell, however micetro does > not. I suppose this is likely outside the scope of this userlist and I'll > follow up further in that with bluecat. > > CS, cs.temp.m...@gmail.com > > > On Thu, 14 Mar 2024 at 12:32, Rick Frey <grib...@gmail.com > <mailto:grib...@gmail.com>> wrote: >> When “cert-required” is set to true, you must provide a client certificate >> and key to authenticate. A client cert is not required for using TLS >> connection (a server cert is). The client cert can be used in lieu of >> username/password. In the case of kea-shell, this is done with —cert and >> —key arguments. >> >> The —ca (CA) is the CA cert used to sign the server’s certificate so the >> client (kea-shell) trusts the server’s (self signed in your case) >> certificate. It is not the client’s cert used for authentication. If you >> are using a client cert, it is generated separately from the server cert but >> is typically signed by the same CA used to sign the server cert when using >> self signed certs. >> >> Since you are passing username/password args to kea-shell, it would appear >> you are not wanting to use a client cert. If you not looking to use a >> client certificate for authentication use username/password instead, you’ll >> just need to set “cert-required” to false in your server config. >> >> >> >>> On Mar 14, 2024, at 13:41, CS <cs.temp.m...@gmail.com >>> <mailto:cs.temp.m...@gmail.com>> wrote: >>> >>> Thanks for the reply Rick. In this deployment I have specified in the >>> control agent conf: >>> "cert-required": true, >>> "trust-anchor": "Certificate_Autority.pem", >>> "cert-file": "ca1_cert.pem", >>> "key-file": "ca1_key.pem", >>> >>> all pointing to self signed certs created with the help of (basically) the >>> script I worked on in the reddit link. Stripping the certs away certainly >>> allows the kea-shell commands to work, however this isn't the goal. >>> >>> I don't understand the second part of your reply. >>> >or is set to true and you did not provide one in the sample command line. >>> >>> Don't I show what you are suggesting I might not have done? "--ca >>> Certificate_Autority.pem" >>> >>> CS, cs.temp.m...@gmail.com >>> >>> >>> On Thu, 14 Mar 2024 at 11:22, Rick Frey <grib...@gmail.com >>> <mailto:grib...@gmail.com>> wrote: >>>> I believe that error indicates your Kea server requires a client >>>> certificate. Per Kea documentation, the config parameter "cert-required” >>>> default is true. Would indicate your server config didn’t set or is set >>>> to true and you did not provide one in the sample command line. If you >>>> don’t require client cert for authentication, you can set to false in >>>> kea-ctl-agent.conf. >>>> >>>>> On Mar 13, 2024, at 16:11, CS <cs.temp.m...@gmail.com >>>>> <mailto:cs.temp.m...@gmail.com>> wrote: >>>>> >>>>> Hey guys, >>>>> >>>>> What does this mean? >>>>> Failed to run: [SSL: TLSV13_ALERT_CERTIFICATE_REQUIRED] tlsv13 alert >>>>> certificate required (_ssl.c:2578) >>>>> >>>>> I'm back again after getting pulled off onto other projects, I am working >>>>> on getting my small kea cluster running with Micetro. >>>>> >>>>> Micetro refuses to add the servers and while I'd thought I had solved all >>>>> my problems with ya'll before (kea daemons appear to be running error >>>>> free) on re-approaching the problem I have notice I have not been able to >>>>> get kea-shell to run against either localhost or the other server. >>>>> >>>>> My knowledge of creating and using SSL is very poor. For this project >>>>> alone I worked with the folks on reddit to develop a script for creating >>>>> the self signed certs. >>>>> https://www.reddit.com/r/openssl/comments/170r9ko/creating_self_signed_cert_for_kea_encryption/?utm_source=share&utm_medium=web2x&context=3 >>>>> so I assume the error is somewhere there. But I don't understand the >>>>> reply when I run kea-shell. >>>>> >>>>> kea-shell --host 10.111.45.45 --port 8000 --auth-user "bad username" >>>>> --auth-password "bad password" --ca certs/Certificate_Autority.pem >>>>> list-commands >>>>> Failed to run: [SSL: TLSV13_ALERT_CERTIFICATE_REQUIRED] tlsv13 alert >>>>> certificate required (_ssl.c:2578) >>>>> >>>>> Do you all know what I've done wrong or what I need to do to make the >>>>> cert right? >>>>> >>>>> CS, cs.temp.m...@gmail.com >>>>> -- >>>>> 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 <mailto:Kea-users@lists.isc.org> >>>>> https://lists.isc.org/mailman/listinfo/kea-users >>>> >>>> -- >>>> 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 <mailto:Kea-users@lists.isc.org> >>>> https://lists.isc.org/mailman/listinfo/kea-users >>> -- >>> 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 <mailto:Kea-users@lists.isc.org> >>> https://lists.isc.org/mailman/listinfo/kea-users >> >> -- >> 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 <mailto:Kea-users@lists.isc.org> >> https://lists.isc.org/mailman/listinfo/kea-users > -- > 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
-- 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
