develooper Front page | perl.perl5.porters | Postings from June 2022

Re: Pre-RFC: support https out-of-the-box

Thread Previous | Thread Next
Alexander Hartmaier
June 20, 2022 07:08
Re: Pre-RFC: support https out-of-the-box
Message ID:
On Thu, Jun 16, 2022 at 2:38 AM Felipe Gasper <>

> > On Jun 15, 2022, at 18:22, Craig A. Berry <>
> wrote:
> >
> > On Wed, Jun 15, 2022 at 2:23 AM Alexander Hartmaier
> > <> wrote:
> >>
> >> On Tue, Jun 14, 2022 at 6:18 PM Elvin Aslanov <>
> wrote:
> >>>
> >>> yeah but `cpan Mozilla::CA` isn't hard to do to update the module and
> it won't break with newer Perl versions as well since it's just plaintext
> non-code certificates bundle
> >>
> >>
> >> I'd prefer if the stack used the OS trusted CAs by default instead of
> having its own list.
> >> This should only be the default and overrideable for private CA
> use-cases.
> >
> > But that is a *massively* more difficult portability problem than just
> > "where do I find OpenSSL or LibreSSL?".  Do you know where the OS
> > trusted CAs are for every platform and distribution on which Perl
> > runs? Or if there even is such a thing as an "OS trusted CA" on all of
> > them?  Or what format they are in?  Or whether they even exist on the
> > filesystem or are in some proprietary data store?
> Clarification: by “OS-trusted CAs” I believe Alexander refers specifically
> to OpenSSL’s roots, which are easily discoverable via the mechanism I
> mentioned earlier in this thread.
> The idea is: if there’s OpenSSL, use it; if not, no out-of-the-box TLS.
> -FG

I wasn't really talking about OpenSSL but Debian/Ubuntu's ca-certificates
package which puts the trusted root CA cert files in PEM format in
/etc/ssl/certs. I'm sure RHEL and derivates have such a directory as well.
For Windows I don't know how and where they are stored nor how to access
them, but the UI for managing them is launching mmc.exe and adding the
'Certificates' snapin.

That's what a regular user expects, just as usage of a system set proxy,
which is also a topic to make the HTTPS Internet access work.
That's with my 'large enterprise security engineer/architect' hat on.
FYI our current international client network can't even resolve Internet
DNS any more, just the proxy can.
There are also multiple internal root CAs that you have to trust, either
for internal https resource access or even man-in-the-middle TLS (please
don't call it SSL, that long dead) inspection.

I'd split the required parts up into (in order of importance, can also be
shortcut using configure switches if autodetection fails or isn't
implemented for a platform):
- TLS library setup
- trusted root CA certificate detection (different per OS, maybe even dist
- system proxy detection

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About