I'm trying to fetch the following URL via various libraries and command-line tools, but running into a SSL handshake error.
> curl https://www.joelosteen.com/Views/RSS/Feed?t=PodcastVideo&ct=CustomList&cst=Podcasts
curl: (35) error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error
I've seen here it may be fixed by reducing possible ciphers, but trying this less strict call with restricted ciphers doesn't fix it.
curl -vlkL "https://www.joelosteen.com/Views/RSS/Feed?t=PodcastVideo&ct=CustomList&cst=Podcasts" --ciphers DHE-RSA-AES256-SHA
Any ideas how I can fix this? It's a shared account, ie no root available.
The server supports only TLS version 1.2, i.e. no TLS 1.0 or even SSL 3.0. My guess is that the curl you use is simply too old to use TLS 1.2, but without further details about the version you use this guess can not be verified.
To determine the version of curl use curl --version. If you see it is compiled with OpenSSL than it should show at least version 1.0.1 of OpenSSL to have TLS 1.2 support.
curl -vlkL ... --ciphers DHE-RSA-AES256-SHA
This is not a cipher supported by the server. One of the ciphers supported is AES128-SHA but again, no chance if your curl does not support TLS 1.2.
Related
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
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!
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
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
One of the sites I manage started having a problem recently where if you try to access it via chrome (and apperently opera, and new edge) I get the ERR_SSL_PROTOCOL_ERROR error page. And unfortunantly there is not further information I have been able to find about what the underlying error actually is.
All of the suggestions elsewhere list things wrong on the client side except server clock skew - which existed but was fixed with no effect on the error.
running echo | openssl s_client -servername <site_url> -connect <site_url>:443 on mac gives a successful tlsv1.2 response.
running https https://<site_url> gives a successful HTTP response.
The site works in IE11, Firefox, Edge (old) as well as with openssl commandline.
The site is wordpress running on Ubuntu 14.04 (openssl version 1.0.1f) with PHP 5.6 and nginx 1.6.2
As I said above - I have already corrected the ~3 minute clock skew on the server that could cause ssl failure.
Any help is appreciated.
--Update--
I get the following protocol vulnuablities when checking on SSLLab
SSL labs protocol section
Server SSL Protocols: TLS 1.1, TLS 1.2 are enabled in the server
Works with REDCapR library which is using the same handshake protocol. I've verified the request headers with the fiddler tool. This proves that the server is accepting sslv3 alert handshakes successfully. I'm not sure why RCurl is failing for the same protocol.
Let me know if you need any more information. Thanks in advance!
Curl - Version 3.2,
RCurl - Version 1.95-4.11,
httr - Version 1.3.1,
openssl - Version 1.1
does anybody if is possible to disable TLS v1 in Corda Artemis. I know Corda use TLS v1.2 but our problem is TLS v1 is enable in the system.
If I run "openssl s_client -connect IP:port -tls1" I get a sucessfully respond. Is there a way to disable TLS v1 in corda? Thanks!! –
TLS1 is not enabled. If you run openssl s_client -connect IP:port -tls1 and try and connect to a node, you get a wrong version number error, indicating that TLS1 is not supported.
The list of supported TLS versions can be found here: https://github.com/corda/corda/blob/master/node-api/src/main/kotlin/net/corda/nodeapi/ArtemisTcpTransport.kt. Only v1.2 is supported.
I have a Mac running OS X Server 5.2 and due to company policy I need to force the server to use TLS 1.2 only and turn off TLS 1 and TLS 1.2.
I have edit the conf files in the /Library/Server/Web/Config/apache2/sites to SSLProtocol -all +TLSv1.2 but it still allows connection with tls1 and tls1.2
Does anybody know how to enforce TLS 1.2 connections only?
Thanks!
If that is an option, update your Server app. Starting with Server version 5.3, support for TLS 1 and TLS 1.1 has been disabled by default, so this solution would be simple and effective.
If you cannot update for some reason, you will have to remove these protocols in /Library/Server/Web/config/proxy/apache_serviceproxy.conf, and possibly in /library/server/web/config/apache2/httpd.conf. Also note that I have found that you have to restart macOS in order to restart the proxy server (it is not sufficient to issue sudo serveradmin stop/start web). This seems to be unnecessary - see my update below!
Update
It looks like there is a bug in Apache that can prevent the above setting from working as expected. It seems that, if there ciphers active that are not allowed any more in TLS 1.2, the older TLS versions remain available despite the setting in SSLProtocol. These older cipher suites need to be deactivated as well.
Therefore, use this recommended configuration:
SSLProtocol -all +TLSv1.2
SSLCipherSuite ALL:+HIGH:!ADH:!EXP:!SSLv2:!SSLv3:!MEDIUM:!LOW:!NULL:!aNULL
SSLHonorCipherOrder on
Besides that, it looks like it's enough to update /Library/Server/Web/config/proxy/apache_serviceproxy.conf, as SSL/TLS is handled by the proxy process only. To restart the proxy use
$ sudo launchctl unload -w /Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/com.apple.serviceproxy.plist
$ sudo launchctl load -w /Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/com.apple.serviceproxy.plist
A server restart is not required.
There might be multiple occurrences in the configuration. I replaced them all, which may or may not be necessary.