pypi remote repository fails SSL Test

user_3440431 0
Viewed 345

It appears sometime in June of this year our SSL validation inside of Artifactory started to fail for https://files.pythonhosted.org. As a result we are no longer able to resolve remote lookups for python packages not hosted locally.

The error when I click Test on the remote repository settings page with https://files.pythonhosted.org as the hostname:

Connection to remote repository failed: Certificate for doesn't match any of the subject alternative names: [r.shared-319-default.ssl.fastly.net]

When I try to validate the SSL using openssl on the host linux server:

openssl s_client -connect files.pythonhosted.org:443
subject=/CN=r.shared-319-default.ssl.fastly.net

If I pass the servername flag to openssl it finds the right cert:

openssl s_client -servername files.pythonhosted.org -connect files.pythonhosted.org:443
subject=/CN=*.pythonhosted.org

How do I go about fixing this in the UI?
server: CentOS Linux release 7.7.1908 (Core)
artifactory version: EnterpriseX license 7.3.2 rev 70302900
pypy remote settings

EDIT Appears this is most likely caused by the version of artifactory this specific instance is running. I was able to check a newer version than what this instance is running and it works correctly.

EDIT2 The system.yaml contained the following

extraJavaOpts: -Djsse.enableSNIExtension=false
this was disabling artifactory from resolving SNI enabled domains. Fixed!

artifactory
2 Answers

I tested the reported scenario. Executing an openssl command to retrieve the certificate from the Python registry is returning certificates with a different CN apart from the expected one.

Command:

openssl s_client -showcerts -connect files.pythonhosted.org:443 </dev/null

I couldn't confirm if this is an issue with a redirect. However, executing the command to retrieve the certificate with server name in specific appears to be revealing the actual certificate for the remote site. So, Could you please try using the following command, collect the certificate and use this certificate to replace the already amended certificates in support of this remote connection?

openssl s_client -showcerts -connect files.pythonhosted.org:443 -servername files.pythonhosted.org </dev/null
user_123780940

I'm not familiar with the artifactory you mentioned. But I can give you a hint on the certificate part, in general, your issue is caused by the website files.pythonhosted.org support SNI and your client-side cannot recognize the SNI support.

To check the server website ssl information, you can visit: https://www.ssllabs.com/ssltest/analyze.html?d=files.pythonhosted.org&s=151.101.1.63

In the result, you can see a line "Certificate #2: RSA 2048 bits (SHA256withRSA) No SNI" which means there are 2 certificates in the server, and for more explanation, you can check https://support.cpanel.net/hc/en-us/articles/360055289933-Why-is-SSLLabs-Certificate-2-RSA-2048-bits-SHA256withRSA-No-SNI-test-showing-an-error-

And OpenSSL older version cannot handle SNI correctly as well, that's why your openssl command is not returning the expected result. Actually, the same command

openssl s_client -showcerts -connect files.pythonhosted.org:443

with OpenSSL 1.0.2k-fips on Oracle Linux 7, it returns: r.shared-319-default.ssl.fastly.net

with OpenSSL 1.1.1 FIPS on Centos 8, it returns: *.pythonhosted.org

So the issue may be related to https://www.jfrog.com/jira/browse/HAP-556 https://www.jfrog.com/jira/si/jira.issueviews:issue-html/BI-167/BI-167.html

user_60424560
Related