Could not upload tarball to PAUSE from server

[James E Keenan]

Tonight I attempted to upload to PAUSE a trial version of a CPAN
distribution I maintain. I built and tested a tarball on my desktop,
then scp-ed the tarball to my Linode server. I then signed in to PAUSE
and put the URL to the tarball in the appropriate box. I usually expect
to get an upload notification within minutes and, soon thereafter, see
it entering the metabase log file. I have done CPAN uploads like this
many dozens of times.

Tonight, however, I did not get any upload notification email and did
not see the file entering metabase. Instead, after several hours, I got
an email from "PAUSE <upl...@pause.perl.org>" with this content:

#####
The URL
https://thenceforward.net/perl/modules/Devel-NYTProf/Devel-NYTProf-6.12_001.tar.gz,
requested for upload as J/JK/JKEENAN/Devel-NYTProf-6.12_001.tar.gz has
problems[.] I have retried to fetch it 8 times to no avail. I'll
continue to try until the maximum of 16
retries is reached. Then I'll give up to give room for a new trial.
#####

I incremented $VERSION and tried again. This did not appear to work.

I incremented $VERSION again and asked PAUSE to fetch the tarball
directly from my desktop -- i.e., not from my server. This succeeded.

The only thing which I think is different from my last CPAN upload is
that about a month ago I upgraded my server from http:// to https://. I
have not encountered any problems with the server since then. The file
permissions on the tarballs I was trying to upload are 0644 -- same as
all the other dozens of tarballs I've uploaded from that server.

Any ideas as to why I could not upload from my server (for the first
time in 18 years!)?

Thank you very much.
Jim Keenan

[Tony Cook]

On Sat, Oct 07, 2023 at 10:37:36PM -0400, James E Keenan wrote:
> The only thing which I think is different from my last CPAN upload is that
> about a month ago I upgraded my server from http:// to https://. I have not
> encountered any problems with the server since then. The file permissions
> on the tarballs I was trying to upload are 0644 -- same as all the other
> dozens of tarballs I've uploaded from that server.
>
> Any ideas as to why I could not upload from my server (for the first time in
> 18 years!)?

For some reason it can't verify the certificate:

2023-10-08 02:47:59 $$1354 v1049: Alert: nosuccesscount[10] error[Can't connect to thenceforward.net:443 (certificate verify failed)] (paused:708)

You might try testing your site with:

https://www.ssllabs.com/ssltest/

which will detect problems that might not show in a browser.

It might be the host performing the fetch is missing the root
certificate needed for your LetsEncrypt certificate, but ssltest is
the place to start.

Tony

[James E Keenan]

On 10/7/23 23:33, Tony Cook wrote:
> On Sat, Oct 07, 2023 at 10:37:36PM -0400, James E Keenan wrote:
>> The only thing which I think is different from my last CPAN upload
is that
>> about a month ago I upgraded my server from http:// to https://. I
have not
>> encountered any problems with the server since then. The file
permissions
>> on the tarballs I was trying to upload are 0644 -- same as all the other
>> dozens of tarballs I've uploaded from that server.
>>
>> Any ideas as to why I could not upload from my server (for the first
time in
>> 18 years!)?
>
> For some reason it can't verify the certificate:
>
> 2023-10-08 02:47:59 $$1354 v1049: Alert: nosuccesscount[10]
error[Can't connect to thenceforward.net:443 (certificate verify
failed)] (paused:708)
>
> You might try testing your site with:
>
> https://www.ssllabs.com/ssltest/
>
> which will detect problems that might not show in a browser.

When I switched from http:// to https:// in late September, I performed
that ssltest on each of the three hosts I run off this machine/IP
address. Two of the three hosts were graded 'A'; one (which is not as
important) was graded 'A' but only for IPv4.

####
https://www.ssllabs.com/ssltest/analyze.html?d=thenceforward.net A
https://www.ssllabs.com/ssltest/analyze.html?d=jamesekeenan.com A
https://www.ssllabs.com/ssltest/analyze.html?d=lerner-minsky.org A only
on ipv4
####

I re-performed these tests this morning. In my first pass for
thenceforward.net (which is the hostname PAUSE would have been looking
for), the test hung indefinitely showing an ever spinning spike-wheel
and "Please wait...Testing NPN"

My first pass for jamesekeenan.com got farther in the process. After
about 10 minutes it was still at: "Please wait... 95% complete
Simulating handshakes". The process then appeared to hang indefinitely.

I hit the Clear Cache process and started anew testing
thenceforward.net. This time the process gave me an Overall Rating of
'A' (better than google.com!) along with a wealth of other data, most of
which did not seem anomalous. In what follows I'm only pointing out
those anomalies:

#####
Certificate #1: EC 256 bits (SHA256withRSA): Only thing which looks
anomalous is: "DNS CAA No (more info)"

Subject thenceforward.net
Fingerprint SHA256:
d71a64c0cb54787620cf4341ae28041b7e1b1d173785443337bbb2eb4d2923cb
Pin SHA256: P5vJZqpxQIYZPF3D8iMCtr5q/3eE6XlQyzK/IWnm60U=
Common names thenceforward.net
Alternative names thenceforward.net www.thenceforward.net
Serial Number 041ea3bd1884e0f09546ccd19e8b061c6588

Additional certificates (if supplied): R3 no anomalies. ISRG Root X1
no anomalies.

Certification Paths:

Mozilla / Apple / Java

Path #1: Trusted: no anomalies

Path #2: Not trusted (path does not chain to a trusted anchor): DST
Root CA X3 Self-signed
* This is described as Extra download; Not in trust store. RSA 2048
bits (e 65537) / SHA1withRSA
Valid until: Thu, 30 Sep 2021 14:01:15 UTC
EXPIRED
Weak or insecure signature, but no impact on root certificate

Android / Windows

RSA 2048 bits is in trust store but has expired

Certificate #2: EC 256 bits (SHA256withRSA) No SNI

Subject jamesekeenan.com
Fingerprint SHA256:
e64efa87924731fb4e7e1e893e61b46e1745299f249d5186c6dfe638f6d75df3
Pin SHA256: OonVyaTHdqBFC4MU4xN3fEko/1BdMoqGNswfbXx8DGI=
Common names jamesekeenan.com
Alternative names jamesekeenan.com www.jamesekeenan.com MISMATCH
#####

>
> It might be the host performing the fetch is missing the root
> certificate needed for your LetsEncrypt certificate, but ssltest is
> the place to start.
>

Is there any indication in the data above to support that hypothesis?
If not, where do we go from here?

> Tony

Thank you very much for taking the time to review this problem.

Jim Keenan

[Tony Cook]

On Sun, Oct 08, 2023 at 09:59:10AM -0400, James E Keenan wrote:
> > It might be the host performing the fetch is missing the root
> > certificate needed for your LetsEncrypt certificate, but ssltest is
> > the place to start.
> >
>
> Is there any indication in the data above to support that hypothesis? If
> not, where do we go from here?

Not that I can see.

I suspect this is something Andreas would need to resolve.

It's possible it was a temporary problem, so you should try again
before contacting Andreas.

Tony

[James E Keenan]

I did try again, with the same results. I then contacted Andreas, who
said that (a) this is a known problem, i.e., PAUSE is currently unable
to fetch tarballs for upload from https://; (b) it won't be fixed until
the new PAUSE server gets installed.