--- Begin Message ---Classified as: {OPEN} Thank you for these clarifications.I have implemented a basic SSL certificate check by setting a callback in ClientTLSState::setup() In case of self-signed or expired certificate, the SSL connection fails between openRTSP and testOndemandServer. However, I have noticed that just after the connection failure, testOndemandRTSPserver CPU usage increase to 100% ! I didn't succeed to detect the origin of this problem. You can find attached to this mail a patch allowing to reproduce the problem. You have to set the path of a sel-signed certificate in testOndemandRTSPserver.cpp and optionally set the path of CA file in openRTSP.cpp. The problem occurs also if you let SSL check the server certificate using the OS certificate store by setting CA file in openRTSP to NULL. By the way, is it possible to integrate such SSL certificate check into live555 ? This check could be done using the default CAs in the OS certificate store or by providing a private CA file to live555. Yahia {OPEN} -----Message d'origine----- De : Jonathan Brady <jonathan.brady+live...@denbridgemarine.com> Envoyé : mardi 17 juin 2025 13:04 À : live-de...@us.live555.com Objet : Re: [Live-devel] RTSPS and PKI As far as I know with the current client implementation the server certificate is always valid and I believe additional work is required to bypass validity checks and allow things like self signed certificates. A client could check this, but it would require work to do this in ClientTLSState::setup. After SSL_CTX_new I believe you would need to add a call SSL_CTX_set_verify with a verification callback which could be used to inspect the server certificate and bypass checks. I'm not sure it's worth the effort. However it might be useful to add a virtual function call after the if (fCtx == NULL) check to allow the user to make changes to the context, e.g. setting allowed TLS versions, allowed encryption methods, ciphers etc. The same goes for ServerTLSState::setup a virtual function might be useful to allow the user to customise the context, if you do so I'd move the 3 calls between SSL_CTX_new and SSL_new in setup into that virtual function, maybe have it return a boolean value to replicate the current break statements. On 17/06/2025 10:21, Ross Finlayson wrote: > >> On Jun 17, 2025, at 2:13 AM, BENMOUSSA Yahia - Contractor via live-devel >> <live-de...@us.live555.com> wrote: >> >> At the client side, how we can check the validity of the server certificate ? >> For ex. It is self-signed certificate or not. > As far as I know, there’s no way for the client to check this. Once the TLS > connection succeeds, it is assumed to be valid. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > live-devel@lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel
ca.patch
Description: ca.patch
--- End Message ---
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
