TNetHttpCLient trusted CA

[sfrazor 3]

It looks like TNetHTTPClient trusts all CA's by default.  Then leaves it up to the developer to verify the public key.  But, is there a way to only allow  or validate against a specific CA?  

I've done some searching and reading and Indy comes up with some examples but I don't see anything on TNetHTTPClient and how to accomplish this.

 

[sfrazor 3]

At the moment I'm playing with TNetHTTPClient.UseDefaultCreedentials:= False to turn off the default credential validation then TNetHTTPClient.CredentialStorage.AddCredentials(MyCreds);

Trying to turn off the accept ALL CA's and insert my own.  I have no idea if I'm heading in the right direction.  
I don't see any good examples of how to add my own CA cert and validate a server CA against it.

Edited April 27, 2023 by sfrazor

[Fr0sT.Brutal 900]

It uses WinAPI on Windows (are you on Windows?) so you likely have to investigate a WinAPI way of temporarily adding your desired CA

Edited April 28, 2023 by Fr0sT.Brutal

[sfrazor 3]

Thanks Frost.  I did end up using the windows API like you mentioned.  Not what I would have liked.  

I would have used Indy if they had a way to eliminate the openssl distribution requirement.  On that note, I see there is an option for YUOpenSSL (or whatever its called) that interests me.  But no step-by-step for dummies (that I find) on how to implement it.  Add the compiler options, add the YUOpenSSL library and install the new alternate Indy in to Delphi.  But its promising.  Indy has all of the above Cert details surfaced which is what I really need.

[Fr0sT.Brutal 900]

ICS lib has ability to use commercial embeddable OpenSSL version. In theory there's a chance to build cURL which can embed TLS engine as OBJ files and link them statically but that would be a mess

[sfrazor 3]

11 hours ago, Fr0sT.Brutal said:

ICS lib has ability to use commercial embeddable OpenSSL version. In theory there's a chance to build cURL which can embed TLS engine as OBJ files and link them statically but that would be a mess

Yes, I saw that ICS also has the ability to build against YUOpenSSL.    I may have to hit up Remy for some hand  holding  if I decide to use Indy and YUOpenSSL.  If we work it out, I'll post the details here.  

 

Edited May 10, 2023 by sfrazor

[Fr0sT.Brutal 900]

Out of curiosity - what's the reason of " eliminate the openssl distribution requirement. "?

[sfrazor 3]

On 5/11/2023 at 2:39 AM, Fr0sT.Brutal said:

Out of curiosity - what's the reason of " eliminate the openssl distribution requirement. "?

Hey Frost, Sorry for the late reply.  I can make suggestions for projects when things just don't make sense.  This forum is good at pointing those things out.   Like why no SSL dll's.  But the short of it is, the requirement of packaging a single deliverable executable or DLL which the PM describes as no openssl DLL's if at all possible.  This leaves me with Indy and ICS for comms components using YuOpenSSL.   

[Angus Robertson 574]

YuOpenSSL operates identically to the SSLs in ICS, I've been using it as both Win32 and Win64 in my server and client applications for two years.  But then I did adapt ICS to use YuOpenSSL.

 

ICS also has full X509 certificate validation against CA stores I update every few months, including an internal store to avoid needing CA files, and checks OCSP for withdrawn certificates. 

 

Angus

 

[mezen 13]

On 4/27/2023 at 6:17 PM, sfrazor said:

It looks like TNetHTTPClient trusts all CA's by default.  Then leaves it up to the developer to verify the public key.  But, is there a way to only allow  or validate against a specific CA?  

I've done some searching and reading and Indy comes up with some examples but I don't see anything on TNetHTTPClient and how to accomplish this.

 

THTTPClient (from unit System.Net.Client) uses OS specific implementations. On Windows it uses the WinHTTP API. WinHTTP uses the Windows Certificate Store and Microsofts Trusted Root Certificate List.

 

But it also offers the possibility to use a callback: OnValidateServerCertificate, see https://docwiki.embarcadero.com/Libraries/Sydney/en/System.Net.HttpClient.THTTPClient.FValidateServerCertificateCallback

TValidateCertificateEvent = procedure(const Sender: TObject; const ARequest: TURLRequest; const Certificate: TCertificate; var Accepted: Boolean) of object;

 

You could use a handler, which sets Accepted always to false, except for your specific server certificate (to implement something like certificate pinning).

[Fr0sT.Brutal 900]

On 5/30/2023 at 8:56 PM, sfrazor said:

But the short of it is, the requirement of packaging a single deliverable executable or DLL which the PM describes as no openssl DLL's if at all possible

I still see no answer why these requirements. Moreover, what exact req's are?

[sfrazor 3]

2 hours ago, Fr0sT.Brutal said:

I still see no answer why these requirements. Moreover, what exact req's are?

Right, what I'm saying is our requirements doc produced by our Project Manager dictates what's wanted for a specific dev task.  In this case (and not always) he asked for a single dll deliverable.  The dll is obviously including https comms.  Makes my job interesting to say the least.

[sfrazor 3]

On 5/31/2023 at 4:38 AM, mezen said:

THTTPClient (from unit System.Net.Client) uses OS specific implementations. On Windows it uses the WinHTTP API. WinHTTP uses the Windows Certificate Store and Microsofts Trusted Root Certificate List.

 

But it also offers the possibility to use a callback: OnValidateServerCertificate, see https://docwiki.embarcadero.com/Libraries/Sydney/en/System.Net.HttpClient.THTTPClient.FValidateServerCertificateCallback

TValidateCertificateEvent = procedure(const Sender: TObject; const ARequest: TURLRequest; const Certificate: TCertificate; var Accepted: Boolean) of object;

 

You could use a handler, which sets Accepted always to false, except for your specific server certificate (to implement something like certificate pinning).

Thanks, and yes.  I'm using the callback for validating (cert pinning).  So I was confused.  The components utilize native cert validation unless the callback is in place.  I was confused what the pubkey was and I found out it is the modulus.  My lack of understanding of the validating the cert.  Or overall lack of understanding.  But I'm learning!

Edited June 1, 2023 by sfrazor

[sfrazor 3]

On 5/30/2023 at 1:21 PM, Angus Robertson said:

YuOpenSSL operates identically to the SSLs in ICS, I've been using it as both Win32 and Win64 in my server and client applications for two years.  But then I did adapt ICS to use YuOpenSSL.

 

ICS also has full X509 certificate validation against CA stores I update every few months, including an internal store to avoid needing CA files, and checks OCSP for withdrawn certificates. 

 

Angus

 

Thanks for the response.   I really like ICS.  Last visit to the site there was some info on the use of YuOpenSSL.  I'm going to go search when I'm done here.  Specifically is there a how-to to add YuOpenSSL as an alternative?  Last look it was a  bit cryptic for me to understand.

[Angus Robertson 574]

Using YuOpenSSL with ICS is easy, just uncomment {$DEFINE YuOpenSSL} in the OverbyteDefs.inc unit, add the path of the correct YuOpenSSL.dcu (single file) and rebuild the packages.  I've done it several times this week testing new versions of our OpenSSL DLLs and the DCUs.  You don't need any other YuOpenSSL units.

 

Angus

 

[Fr0sT.Brutal 900]

19 hours ago, sfrazor said:

he asked for a single dll deliverable

You can include necessary binaries to main one as resources and extract them at runtime.