David Beavon (Software) asked a question.
The docs say that IHttpClient is supposed to allow me to bypass host validation. Here are links
https://community.progress.com/s/article/How-to-use-nohostverify-with-the-ABL-HTTPClient
https://community.progress.com/s/article/what-does-the-nohostverify-parameter-actually-do
After much trial and error, I've come to the conclusion there is no way to turn off the TLS cert verification.
I'm trying to configure this skip in pre-prod environments where there aren't dedicated teams willing to micromanage the OE cert store.
In many runtimes there is a callback that allows you to override the certificate validation process. Eg. in c# we have RemoteCertificateValidationCallback on SslClientAuthenticationOptions.
However in ABL I'm totally prevented from influencing the certificate validation, no matter what I do.
The error is like so:
- 443 Secure Socket Layer (SSL) failure. error code -54: self-signed certificate in certificate chain: for 12345
If anyone knows a path forward, in ABL, then I'd love to hear it. I'd rather not use the CLR bridge, just to be able to interact with a web API over HTTPS.
This article seems to describe similar behavior with sslVerifyHost disabled and the root certificate missing in the OE certificate store:
https://community.progress.com/s/article/HTTPClient-using-SslVerifyHost-reports-Error-code-54
Thanks that appears to be the answer I was missing.
What do folks think about making the security team responsible for the cert store, and dropping it on a network drive for
convenience (via "-certstorepath" argument)?
It seems unfortunate if we get pushed into the job of micromanaging the cert store. In a large organization with lots of pre-prod and lots of dev workstations, there is a large number of impacted individuals. It adds a lot of inefficiency to tell everyone to find this KB, and try to deal with managing our certs . It would be better to have code that will just work (IF Environment = "DEV" THEN DO: JUST MAKE IT WORK. END. )
I spent too much time on this. I encountered every TLS error imaginable yesterday. And I was really tempted to switch back to using the CLR bridge, for the sake of TLS alone. It seems crazy to bridge to an entirely different runtime - just to make an outbound HTTP call.
I think I found a pre-existing IDEA for allowing OE to use the OS cert store, but it is old. And there should DEFINITELY be a way to skip verification of certs like in other runtimes. When a dev is doing a P-o-C, or is migrating examples of code from other runtimes (python/c#/java) into ABL, nobody really expects to be tripping over these certificate issues for several hours. It is pretty discouraging.
SHOULD we skip verification of the cert? Of course not. But we are big kids. Just like in the other runtimes, Progress should expect us to take risks into consideration, and make good decisions about our production code. Not everything a developer does on their workstation is going to happen the same way in production.
OpenEdge 13 finally settles on the OS certificate store by default.
That is good to hear, but we still need to be able to skip verification like we can do in other runtimes.
I wouldn't say it is settled. I'd say that for 90% of my scenarios using the OS cert store is good enough. However there is still 10% where we need to skip verification. Some ABL developers don't manage their local cert store, but they should be able to add a line of code to ABL, in order to get unblocked on a P-o-C.
In other cases a software developer may be building their own WIP web service, and writing the ABL client-side to connect to it as well. The cert may be self-signed and used in kestrel server, and there is really no point in going thru the whole ceremony of moving it into the cert authority (either the OS one or the OE one). There are plenty of scenarios where we shouldn't have to verify certs if we don't want to - just as we can do in all the other programming runtimes.
Heck, even an end user is allowed to browse to a HTTPS web page that doesn't have a valid certificate. (they may have to side-step a warning). If an end user can accomplish this in a browser, then surely Progress can empower an ABL developer to do a similar thing in our dev environment. We don't actually need the extreme coddling from Progress.