Question 27110 in CentOS Question posted in
The official documentation can be found here.

pypi remote repository fails SSL Test – CentOS

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!

Tags:

2

Answers


  1. 0

    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
    Login or Signup to reply.
  2. 0

    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

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search