I might be obscuring things by troubleshooting XMLRPC::Lite when I could be troubleshooting LWP.

use LWP::UserAgent;
use HTTP::Request::Common;

$ENV{'PERL_LWP_SSL_VERIFY_HOSTNAME'} = 0;

my ($response_content, $response_status);

my $userAgent = LWP::UserAgent->new();
$userAgent->agent("PhilPerl");

my $request = HTTP::Request->new();
$request->method('GET');
$request->uri('https://perlmonks.org');

my $response = $userAgent->request($request);
[download]

Gets me a $response that seems more helpful. The gist of which is:

But I do have a C:\Strawberry\perl\site\lib\auto\Net\SSLeay\SSLeay.xs.dll so I'm not sure what to make of that.

Can't load 'C:/Strawberry/perl/site/lib/auto/Net/SSLeay/SSLeay.xs.dll' for module Net::SSLeay: load_file:The specified module could not be found (LWP::Protocol::https not installed)

The (second) script that you provided works fine for me on 64-bit Strawberry Perl 5.32.1.1. I'm therefore pretty certain that there's something broken in your environment - perhaps some interference from some old perl installation.

I think you should be able to reproduce that error by simply trying to "use Net::SSLeay" :

perl -MNet::SSLeay -e 1
[download]

I added a bit to your script, to reveal the contents of $response:

use LWP::UserAgent;
use HTTP::Request::Common;

$ENV{'PERL_LWP_SSL_VERIFY_HOSTNAME'} = 0;

my ($response_content, $response_status);

my $userAgent = LWP::UserAgent->new();
$userAgent->agent("PhilPerl");

my $request = HTTP::Request->new();
$request->method('GET');
$request->uri('https://perlmonks.org');

my $response = $userAgent->request($request);

if ($response->is_success) {
  print $response->decoded_content;
}
else {
  die $response->status_line;
}
[download]

For me, that worked fine and successfully retrieved the requested page.

Even if I effectively remove LWP::Protocol::https (by renaming perl/vendor/lib/LWP/Protocol/https.pm to perl/vendor/lib/LWP/Protocol/https.pm_hide) the script still runs fine.
However, in this instance, $response merely contains the message "501 Protocol scheme 'https' is not supported (LWP::Protocol::https not installed) at try.pl line 21."

In addition to the checks already mentioned, take a look at what's in your PATH (perl -le "print $ENV{PATH}) as that's what SSLeay.xs.dll searches (in sequence) for the dlls it needs.
And it will load the first one it finds whose name (case-insensitively) matches the name it's looking for.

Your SSLeay.xs.dll needs to load msvcrt.dll, kernel32.dll, libcrypto-1_1-x64__.dll, libssl-1_1-x64__.dll and perl532.dll.
The first 2 are system files - there should be no problem there.
The last one is the perl-5.32.x dll - there should be no problem there unless there's another perl532.dll found earlier in the path.
And the remaining 2 are given such StrawberryPerl-specific names that it's very unlikely there's a problem there.
It's a bit of a mystery !!

Cheers,
Rob

As at least two of you pointed out, I could reproduce the error easily by useing either LWP::Protocol::https or Net::SSLeay .

I owe you all an apology. I've lurked here long enough to know how much care you put into your responses, and yet I neglected to mention that my scripts are running under IIS. While I could reproduce the error by using either of the above mentioned modules, they both load fine from the command line.

This is resolved. With your suggestions I realized that my command line and IIS $ENV{path} values didn't match. Reason being the machine is already in production so I didn't want to restart IIS, and Strawberry Perl was installed after IIS was started, so IIS and the Perl processes that it spawned had a few paths missing.

Thanks everyone.

Here's some troubleshooting tips. You'll need to make a few adjustments for your MSWin vs. my Cygwin: double quotes around perl commands springs to mind; there may be others.

If cpan is telling you "LWP::Protocol::https is up to date", but perl is telling you "LWP::Protocol::https not installed", that generally suggests you're running different versions. They should be in the same directory:

$ which perl
/home/ken/perl5/perlbrew/perls/perl-5.36.0/bin/perl

$ which cpan
/home/ken/perl5/perlbrew/perls/perl-5.36.0/bin/cpan
[download]

Check what's in @INC:

$ perl -E 'say for @INC'
/home/ken/perl5/perlbrew/perls/perl-5.36.0/lib/site_perl/5.36.0/cygwin
+-thread-multi
/home/ken/perl5/perlbrew/perls/perl-5.36.0/lib/site_perl/5.36.0
/home/ken/perl5/perlbrew/perls/perl-5.36.0/lib/5.36.0/cygwin-thread-mu
+lti
/home/ken/perl5/perlbrew/perls/perl-5.36.0/lib/5.36.0
[download]

perl -V will give you that information and a lot more. There could be something useful in that output.

Try to load just the module:

$ perl -e 'use LWP::Protocol::https'
[download]

That will just return (no output) on success or you might get "Can't locate LWP/Protocol/https.pm in @INC ...".

If that was successful, get more information:

$ perl -E 'use LWP::Protocol::https; say $LWP::Protocol::https::VERSIO
+N; say $INC{"LWP/Protocol/https.pm"}'
6.10
/home/ken/perl5/perlbrew/perls/perl-5.36.0/lib/site_perl/5.36.0/LWP/Pr
+otocol/https.pm
[download]

Note that last line of output should match a directory in @INC obtained earlier. In my case:

/home/ken/perl5/perlbrew/perls/perl-5.36.0/lib/site_perl/5.36.0
[download]

See how you go with those. A solution might present itself. If still stumped, post all output from those commands and we can look into it further.

— Ken

I suspect it's actually referring to a library linked by SSLeay.xs.dll.

Trace it with depends.exe