For our project we build libcurl from scratch over cmake. The libcurl-configure-out.log tells me it enabled HTTPS (among others), heres the important part about that:
-- Enabled features: SSL IPv6 unixsockets AsynchDNS Largefile alt-svc HSTS NTLM HTTPS-proxy
-- Enabled protocols: DICT FILE FTP FTPS GOPHER GOPHERS HTTP HTTPS IMAP IMAPS LDAP MQTT POP3 POP3S RTSP SCP SFTP SMB SMBS SMTP SMTPS TELNET TFTP
-- Enabled SSL backends: OpenSSL
But when I try to set a TLS version in our code, it says "CURLE_NOT_BUILT_IN"
const CURLcode state = curl_easy_setopt(this->m_curl, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_2);
// state == 4 aka "CURLE_NOT_BUILT_IN"
I also tried to verify over the curl executable, which kinda gives me the same impression
C:<snip>\build\ex_libcurl-prefix\src\ex_libcurl-build\src\Debug>curl.exe --version
curl 7.80.0 (Windows) libcurl/7.80.0 libssh2/1.10.0
Release-Date: 2021-12-10
Protocols: dict file ftp gopher http imap ldap mqtt pop3 rtsp scp sftp smb smtp telnet tftp
Features: AsynchDNS HSTS IPv6 Largefile NTLM UnixSockets alt-svc
Where did I go wrong?
Edit: Some more parts about SSL beeing enabled:
-- Found OpenSSL: optimized;C:/Program Files/OpenSSL-Win64/lib/VC/libcrypto64MD.lib;debug;C:/Program Files/OpenSSL-Win64/lib/VC/libcrypto64MDd.lib (found version "3.0.0")
-- Looking for openssl/crypto.h
-- Looking for openssl/crypto.h - found
-- Looking for cldap_open in wldap32;winmm;ws2_32;OpenSSL::SSL;OpenSSL::Crypto
-- Looking for cldap_open in wldap32;winmm;ws2_32;OpenSSL::SSL;OpenSSL::Crypto - found
I have an C++ application which is using curl 7.61.1 version.
while trying to connect to device using ssl I get this error:
"Protocol https not supported or disabled in libcurl"
although the default curl version installed in RHEL8 supports https
curl --version
curl 7.61.1 (x86_64-redhat-linux-gnu) libcurl/7.61.1 OpenSSL/1.1.1 zlib/1.2.11 brotli/1.0.6 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) libssh/0.8.3/openssl/zlib nghttp2/1.33.0
Release-Date: 2018-09-05
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz brotli TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL Metalink
please suggest how to configure/use curl with ssl in Redhat Linux 8
This is the flow I use to setup my HTTPS server with SSL.
It works perfectly on Windows, OS X and Ubuntu 13. But it's failing to work on Ubuntu 14 only and I don't know why.
It's not the full code once it's very big, but I can complete with more details if necessary.
SSL_library_init();
m_sslContext = SSL_CTX_new( SSLv23_server_method() );
SSL_CTX_use_certificate_chain_file( m_sslContext, "path/to/certificate.crt" );
SSL_CTX_use_PrivateKey_file( m_sslContext, "path/to/privatekey.pem", SSL_FILETYPE_PEM );
m_mainSocket = ::socket( PF_INET, SOCK_STREAM, IPPROTO_TCP ) );
...
::listen( m_mainSocket, SOMAXCONN );
...
SOCKET childSocketHandle;
while ( ( childSocketHandle = ::accept( m_mainSocket, ... ) ) > 0 )
{
sslChildSocket = SSL_new( m_sslContext );
SSL_set_fd( sslChildSocket, childSocketHandle );
SSL_set_accept_state( sslChildSocket );
...
SSL_read( sslChildSocket, bufferIn, sizeof( bufferIn ) );
...
SSL_write( sslChildSocket, bufferOut, sizeof( bufferOut ) ) );
}
The problem is: when I try to connect from a browser (Google Chrom), it says:
Unable to make a secure connection to the server. This may be a
problem with the server, or it may be requiring a client
authentication certificate that you don't have. Error code:
ERR_SSL_PROTOCOL_ERROR
Other browsers say similar messages...
When I try to connect from wget, I get:
wget https://example.com:443/
--2014-05-01 17:01:33-- https://example.com:443/
Resolving example.com (example.com)... 127.0.1.1
Connecting to example.com (example.com)|127.0.1.1|:443... connected.
ERROR: cannot verify example.com's certificate, issued by ‘/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=00000000’:
Unable to locally verify the issuer's authority.
To connect to example.com insecurely, use `--no-check-certificate'.
I just changed the serial of the certificate to 00000000.
So... If I finally follow the wget message and do...
wget https://example.com:443/ --no-check-certificate
... THEN the server works perfectly!
So, the conclusion I get is: the server itself IS working, but the handshake has some problem with the SSL certificate. The certificate is valid, used in other servers, Apache accepts it perfectly and as I told, once again, this same implementation works on Windows, OS X and Ubuntu 13. This problem is only happening on Ubuntu 14.
Things I tried to do:
I tried to update the OpenSSL [compiled it by myself] but nothing
happened.
I tried to try other methods instead of SSLv23_server_method(), nothing happened
I compiled in Ubuntu 13 and executed in Ubuntu 14 (AND THIS WORKED!)
Weard (item 3) is that if I compile in Ubuntu 13 and run on Ubuntu 14, it works! So maybe some Ubuntu 14 static library is with problem?
Is my SSL implementation correct? What else can be done so I can fix it for Ubuntu 14 and my server work everywhere?
--
I do openssl s_client -connect example.com:443 and get:
CONNECTED(00000003)
140735262471008:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 322 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
It works perfectly on Windows, OS X and Ubuntu 13. But it's failing to work on Ubuntu 14 only and I don't know why.
...
ERR_SSL_PROTOCOL_ERROR
ERR_SSL_PROTOCOL_ERROR indicates the client and server could not agree on a protocol - SSLv3, TLS 1.0, etc. I believe it corresponds to the protocol_version alert of TLS. See RFC 5246, Section 7.2.
OpenSSL has been TLS 1.2 since 1.0.1. See the OpenSSL CHANGELOG. However, Ubuntu prior to 14 disabled TLS 1.1 and TLS 1.2 for interop reasons. See Ubuntu 12.04 LTS: OpenSSL downlevel version and does not support TLS 1.2. Ubuntu 14 (and subsequent) enables TLS 1.1 and TLS 1.2. (And TLS 1.3 is around the corner: The Transport Layer Security (TLS) Protocol Version 1.3 (draft-ietf-tls-rfc5246-bis-00)).
There could be another issues if you have to go through a proxy. The problem is related to the ClientHello size. The ClientHello size increased with TLS 1.1 and TLS 1.2 because of additional cipher suites (more correctly, TLS 1.2 because TLS 1.1 did not add any cipher suites). Size should not matter except some proxies have fixed size buffer and other hard coded limits that simply break the exchange. It is an issue with some F5 and Ironport appliances.
You can test for TLS 1.2 and ClientHello size sensitivity with s_client:
openssl s_client -tls1_2 -connect <server>:<port> -servername <server> \
-cipher "SSL_RSA_WITH_3DES_EDE_CBC_SHA:TLS_RSA_WITH_3DES_EDE_CBC_SHA"
The above connects with TLS 1.2 and uses only 2 cipher suites (4 bytes). If it connects with 2 cipher suites, then drop the -cipher and see if it connects with the 80+ (over 160 bytes) that are builtin.
If it does not connect with TLS 1.2, then try either -tls1 or -ssl3.
EDIT: You problem is an ancient server and TLS 1.1 and TLS 1.2. See below on the steps to isolate the problem.
You have three potential fixes.
First
The first fix is to have the server upgrade to something that's not ancient. If its a proxy, then fix the proxy.
Second
If you need to modify the protocol versions, then perform the following to get SSLv3 or YLS 1.0 only:
m_sslContext = SSL_CTX_new( SSLv23_server_method() );
const long flags = SSL_OP_NO_SSLv2 | SSL_OP_NO_TLSv1_1 | SSL_OP_NO_TLSv1_2;
SSL_CTX_set_options(m_sslContext, flags);
Third
If you need to modify the cipher suite list:
m_sslContext = SSL_CTX_new( SSLv23_server_method() );
const char* const PREFERRED_CIPHERS = "kEECDH:kEDH:kRSA:AESGCM:AES256:AES128:3DES:"
"SHA256:SHA84:SHA1:!aNULL:!eNULL:HIGH:!RC4:!MD5:!SRP:!PSK:!ADH:!AECDH";
res = SSL_CTX_set_cipher_list(m_sslContext, PREFERRED_CIPHERS);
EDIT: You problem is an ancient server and TLS 1.1 and TLS 1.2. You need to use (1) from above, or (2) from above. Ideally, the ancient server would be fixed so everyone can benefit.
TLS 1.2 does not work:
$ openssl s_client -tls1_2 -connect www.example.com:443 -CAfile gd-class2-root.crt
CONNECTED(00000003)
140735211598300:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337:
...
TLS 1.1 does not work:
$ openssl s_client -tls1_1 -connect www.example.com:443 -CAfile gd-class2-root.crt
CONNECTED(00000003)
140735211598300:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337:
...
TLS 1.0 does work:
$ openssl s_client -tls1 -connect www.example.com:443 -CAfile gd-class2-root.crt
CONNECTED(00000003)
depth=2 C = US, O = "The Go Daddy Group, Inc.", OU = Go Daddy Class 2 Certification Authority
verify return:1
...
SSL v3 does work:
$ openssl s_client -ssl3 -connect www.example.com:443 -CAfile gd-class2-root.crt
CONNECTED(00000003)
depth=2 C = US, O = "The Go Daddy Group, Inc.", OU = Go Daddy Class 2 Certification Authority
verify return:1
...
When I try to connect from wget, I get:
...
Unable to locally verify the issuer's authority.
...
So... If I finally follow the wget message and do...
wget https://mydomain.com:443/ --no-check-certificate
... THEN the server works perfectly!
This is a different issue. wget is likely avoiding the issue by incorporating one of the fixes above. A Wirehsark trace would tell you.
Also, if you provided a real server name, we could help you identify the Root CA you should be using (to avoid Unable to locally verify the issuer's authority).
Here's what I am seeing with s_client:
$ openssl s_client -connect www.example.com:443
CONNECTED(00000003)
depth=1 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = http://certificates.godaddy.com/repository, CN = Go Daddy Secure Certification Authority, serialNumber = 07969287
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/OU=Domain Control Validated/CN=*.example.com
i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
...
So you need Go Daddy Class 2 Certification Authority. You can get that from Go Daddy Repository, SSL Certificate Information. The file is gd-class2-root.crt, and you can pass it to s_client and the result is Verify return code: 0 (ok):
$ openssl s_client -connect www.example.com:443 -CAfile gd-class2-root.crt
CONNECTED(00000003)
depth=2 C = US, O = "The Go Daddy Group, Inc.", OU = Go Daddy Class 2 Certification Authority
verify return:1
depth=1 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = http://certificates.godaddy.com/repository, CN = Go Daddy Secure Certification Authority, serialNumber = 07969287
verify return:1
depth=0 OU = Domain Control Validated, CN = *.example.com
verify return:1
---
Certificate chain
0 s:/OU=Domain Control Validated/CN=*.example.com
i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFRTCCBC2gAwIBAgIHKyKXfFXVZjANBgkqhkiG9w0BAQUFADCByjELMAkGA1UE
BhMCVVMxEDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxGjAY
BgNVBAoTEUdvRGFkZHkuY29tLCBJbmMuMTMwMQYDVQQLEypodHRwOi8vY2VydGlm
aWNhdGVzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkxMDAuBgNVBAMTJ0dvIERhZGR5
IFNlY3VyZSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTERMA8GA1UEBRMIMDc5Njky
ODcwHhcNMTQwMzIxMTYyMjU2WhcNMTUwMzIxMTYyMjU2WjA8MSEwHwYDVQQLExhE
b21haW4gQ29udHJvbCBWYWxpZGF0ZWQxFzAVBgNVBAMMDiouc3RheWZpbG0uY29t
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyRsNuqBROD+6RsmkJk7S
KtTpFO5ke92AfWnEnZuKCbbRo/WjmtCPNLQC7fAQxPJb6i/cCt9cusQqlpFjHTg/
lD5Dqoqn/GXMe4hfKbV8VV3NAjWr8f0M/M1ftaL+zo5UtRjdAEIC9ysfbKqqBOxP
hqGPiL0QpkKQ5YZMiz3S4UZzwQ1Unjj43xH4IZFffsdwY5uJqfeoOl/6qBNAQIyg
1Hk00er/+1UlO2hpMe/qjiCZvGSRUat/O51AgyCPFGDmhSEi6rjyeLvEgpILzgR7
K1/BsCe2Kxi+SRIt8UK2jFjXSRnCQyjtgOitbk/sM0afhUUIb7ns95RWAiXt5CpD
0QIDAQABo4IBuzCCAbcwDwYDVR0TAQH/BAUwAwEBADAdBgNVHSUEFjAUBggrBgEF
BQcDAQYIKwYBBQUHAwIwDgYDVR0PAQH/BAQDAgWgMDQGA1UdHwQtMCswKaAnoCWG
I2h0dHA6Ly9jcmwuZ29kYWRkeS5jb20vZ2RzMS0xMDYuY3JsMFMGA1UdIARMMEow
SAYLYIZIAYb9bQEHFwEwOTA3BggrBgEFBQcCARYraHR0cDovL2NlcnRpZmljYXRl
cy5nb2RhZGR5LmNvbS9yZXBvc2l0b3J5LzCBgAYIKwYBBQUHAQEEdDByMCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5nb2RhZGR5LmNvbS8wSgYIKwYBBQUHMAKGPmh0
dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeS9nZF9pbnRl
cm1lZGlhdGUuY3J0MB8GA1UdIwQYMBaAFP2sYTKTbEXW4u6FX5q653aZaMznMCcG
A1UdEQQgMB6CDiouc3RheWZpbG0uY29tggxzdGF5ZmlsbS5jb20wHQYDVR0OBBYE
FOZLbPozya++C27Grhs5pPUut4WFMA0GCSqGSIb3DQEBBQUAA4IBAQBPv85UBt3g
1XGHwZ9ARxpG9InoHRQledSbRckchU35awnIXuXd6pE+kZ7RctR6BywiPRrQnmYm
0D7wHP+BVoN2cZIkTHHgx/hILGTYk47CKyVcL9+WyDd5UXkJYyfdMzfia6dnG4wZ
ucsdR8Ete2do35yZmCZHU5L9KwXarQRuNexbiOqb4kBjUaIhN79NZs1h812QWLLB
+uRhvHOfQuSleEx1ggou/rwaYKNGYrIJl4/kpCquDXbqebkR1B+ad49GD+yBMyOm
/AOfGSU6YTUfZRGjzS2yAozs+QZFUrZTDHyt6Z93OLD+4O07SSAfTD3AlQlG/V1M
KwHuBUl22QD4
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/CN=*.example.com
issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
---
No client certificate CA names sent
---
SSL handshake has read 2765 bytes and written 843 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES128-SHA
Session-ID: 990D00002F519EEFC297CD4CB157B2F7...
Session-ID-ctx:
Master-Key: A4B16EA84F4CD1E8D56A0B601A678AEE...
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1399002932
Timeout : 300 (sec)
Verify return code: 0 (ok)
I built the 64-bit version of nss and am trying to use it to build the curl library using the --without-ssl and --with-nss=NSS_ROOT option.
During the configure stage, I see the following:
checking for PK11_CreateGenericObject in -lnss3... no
checking for NSS_Initialize in -lnss3... no
checking for ssl_version in -laxtls... no
configure: WARNING: SSL disabled, you will not be able to use HTTPS, FTPS, NTLM and more.
configure: WARNING: Use --with-ssl, --with-gnutls, --with-polarssl, --with-cyassl, --with-nss or --with-axtls to address this.
and finally libcurl is build without https support.
curl version: 7.25.0
Host setup: x86_64-unknown-linux-gnu
Install prefix: /usr/local
Compiler: gcc
SSL support: no (--with-{ssl,gnutls,nss,polarssl,cyassl,axtls} )
SSH support: no (--with-libssh2)
zlib support: enabled
krb4 support: no (--with-krb4*)
GSSAPI support: no (--with-gssapi)
SPNEGO support: no (--with-spnego)
TLS-SRP support: no (--enable-tls-srp)
resolver: default (--enable-ares / --enable-threaded-resolver)
ipv6 support: no (--enable-ipv6)
IDN support: no (--with-libidn)
Build libcurl: Shared=yes, Static=yes
Built-in manual: enabled
--libcurl option: enabled (--disable-libcurl-option)
Verbose errors: enabled (--disable-verbose)
SSPI support: no (--enable-sspi)
ca cert bundle: no
ca cert path: no
LDAP support: enabled (OpenLDAP)
LDAPS support: enabled
RTSP support: enabled
RTMP support: no (--with-librtmp)
Protocols: DICT FILE FTP GOPHER HTTP IMAP LDAP LDAPS POP3 RTSP SMTP TELNET TFTP
Can somebody tell me how to resolve this?
Had to set LD_LIBRARY_PATH to
nss-3.12.6/mozilla/dist/Linux2.6_x86_64_glibc_PTH_64_DBG.OBJ/lib
to make it work.
Thanks,
Raj
I want to know if Apache Tomcat supports TLS v1.2 protocol. I didn't find any documentation about this! Thanks!
I have a similar use case, which is to enable Tomcat 7 to strictly use only TLSv1.2, not to fall back to earlier SSL protocols such as TLSv1.1 or SSLv3. The following steps will answer how to enable Tomcat to support TLSv1.2.
I am using: C:\apache-tomcat-7.0.64-64bit and C:\Java64\jdk1.8.0_60.
Following this instruction: https://tomcat.apache.org/tomcat-7.0-doc/security-howto.html. Tomcat is relatively simple to setup SSL support.
From many references I tested many combination, finally I found 1 which will enforce Tomcat 7 to accept TLSv1.2 only. 2 places needed to touch:
1) In C:\apache-tomcat-7.0.64-64bit\conf\server.xml
<Connector port="8443"
protocol="org.apache.coyote.http11.Http11Protocol"
maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
keystoreFile="ssl/.keystore" keystorePass="changeit"
clientAuth="false" sslProtocol="SSL" sslEnabledProtocols="TLSv1.2" />
where
keystoreFile = local self-signed trust store
org.apache.coyote.http11.Http11Protocol = JSSE BIO implementation.
We don't use org.apache.coyote.http11.Http11AprProtocol, because it is powered by openssl. The underlying openssl will fall back to support earlier SSL protocols.
2) When start up Tomcat, enable the following environment parameters.
set JAVA_HOME=C:\Java64\jdk1.8.0_60
set PATH=%PATH%;C:\Java64\jdk1.8.0_60\bin
set CATALINA_HOME=C:\apache-tomcat-7.0.64-64bit
set JAVA_OPTS=-Djdk.tls.client.protocols="TLSv1.2" -Dsun.security.ssl.allowUnsafeRenegotiation=false -Dhttps.protocols="TLSv1.2"
JAVA_OPTS restriction is required, otherwise Tomcat (which is powered by Java8) will fall back to support earlier SSL protocols.
Start up Tomcat C:\apache-tomcat-7.0.64-64bit\bin\startup.bat
We can see JAVA_OPTS appears in Tomcat startup log.
Oct 16, 2015 4:10:17 PM org.apache.catalina.startup.VersionLoggerListener log
INFO: Command line argument: -Djdk.tls.client.protocols=TLSv1.2
Oct 16, 2015 4:10:17 PM org.apache.catalina.startup.VersionLoggerListener log
INFO: Command line argument: -Dsun.security.ssl.allowUnsafeRenegotiation=false
Oct 16, 2015 4:10:17 PM org.apache.catalina.startup.VersionLoggerListener log
INFO: Command line argument: -Dhttps.protocols=TLSv1.2
Then, we can use openssl command to verify our setup. First connect localhost:8443 with TLSv1.1 protocol. Tomcat refuses to reply with Server certificate.
C:\OpenSSL-Win32\bin>openssl s_client -connect localhost:8443 -tls1_1
Loading 'screen' into random state - done
CONNECTED(000001C0)
5372:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:.\ssl\s3_pkt.c:362:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 0 bytes
Connect localhost:8443 with TLSv1.2 protocol, Tomcat replies ServerHello with certificate:
C:\OpenSSL-Win32\bin>openssl s_client -connect localhost:8443 -tls1_2
Loading 'screen' into random state - done
CONNECTED(000001C0)
depth=1 C = US, ST = Washington, L = Seattle, O = getaCert - www.getacert.com
verify error:num=19:self signed certificate in certificate chain
---
Certificate chain
0 s:/C=SG/ST=SG/L=Singapore/O=Xxxx/OU=Development/CN=Myself
i:/C=US/ST=Washington/L=Seattle/O=getaCert - www.getacert.com
1 s:/C=US/ST=Washington/L=Seattle/O=getaCert - www.getacert.com
i:/C=US/ST=Washington/L=Seattle/O=getaCert - www.getacert.com
---
Server certificate
-----BEGIN CERTIFICATE-----
(ignored)
-----END CERTIFICATE-----
subject=/C=SG/ST=SG/L=Singapore/O=Xxxx/OU=Development/CN=Myself
issuer=/C=US/ST=Washington/L=Seattle/O=getaCert - www.getacert.com
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2367 bytes and written 443 bytes
This proves that Tomcat now strictly respond to TLSv1.2 request only.
TLS version 1.2 is supported by the Oracle JDK version 7, in the JSSE implementation. As Tomcat uses JSSE as underlying SSL library, it should be supported from JDK version 1.7 onwards. Also check your enabled SSL cipher suites in Tomcat.
If you are using Apache as a proxy, please check the Apache and underlying OpenSSL documentation.
Some links:
http://docs.oracle.com/javase/7/docs/technotes/guides/security/enhancements-7.html (Java SE 7 Security Enhancements)
http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html
http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html
As mentioned by others, Tomcat supports TLSv1.2 via the JSSE in JDK 7+.
Tomcat does NOT support TLSv1.1 or TLSv1.2 when used with Tomcat Native (APR). See https://issues.apache.org/bugzilla/show_bug.cgi?id=53952.
Update: looks like TLSv1.2 will finally be supported in Tomcat Native 1.1.32 and Tomcat 8.0.15/7.0.57.
I was also looking to upgrade sslProtocol to TLSv1.1 and as mentioned in the below links on Java6 and Java7
Java6
http://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html
Java7
http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html
The SSLContext supported in Java6 are SSL, TLSv1 and in Java7 SSL, TLSv1, TLSv1.1 and TLSv1.2 are supported.
So, to enable TLSv1.1 or TLSv1.2 in tomcat, just upgrade to Java7 and change the sslProtocol in Connector in server.xml of tomcat.