I want to put more than one server certificates in one Java Keystore(All have different CN). How can I config SSL so that when client specifies a hostname, the certificate with matching CN is returned, but if it's not specified, a desired default certificate is always returned.
I know that I can write my own key manager, but is there a simpler way? what is certAlias in Jetty, is it going to solve my problem?
I've seen other posts saying that the first certificate in the keystore is returned if no SNI matched. But in my case, it seems rather random, not to do with the order of certificates.
Thanks!
Your entire question is answered by simply using TLS + SNI properly.
SNI (Server Name Indication) is very old, and very mature. It was first defined back in June 2003 as part of the TLS Extensions Spec RFC 3546 and has had multiple updates since then. (RFC 4366, RFC 6066, and then RFC 9325)
All modern HTTP Clients (be it a browser, or an embedded HTTP client library) will use SNI when talking https to a server (technically, the TLS layer is handling this part). Even the venerable Java java.net.HttpURLConnection supports SNI (in reality, the Java TLS layer is doing this, the client library doesn't have to do anything extra to support SNI over TLS).
SNI has multiple configurations in Jetty.
org.eclipse.jetty.util.ssl.SslContextFactory.Server
.setSniRequired(boolean) - this is the JVM TLS layer behavior for SNI, if the client doesn't provide SNI, or the SNI has no match on the server side, then the TLS layer will respond accordingly.
.setSNISelector(SniX509ExtendedKeyManager.SniSelector) - this is the JVM TLS layer behavior control to select the appropriate certificate alias for the incoming SNI information. The default behavior is found in org.eclipse.jetty.util.ssl.SslContextFactory.Server.sniSelect(String keyType, Principal[] issuers, SSLSession session, String sniHost, Collection<X509> certificates)
org.eclipse.jetty.server.SecureRequestCustomizer
.setSniHostCheck(boolean) the this is post TLS layer, after the HTTP request has been parsed, ensuring that the client TLS SNI information AND client HTTP request authority (Host header in HTTP/1, :authority pseudo header in HTTP/2 and HTTP/3) AND the returned SNI in the server level TLS layer all match.
.setSniRequired(boolean) this ensures that the SNI is used by the client.
I would strongly encourage you to NOT replace the KeyManager with your own implementation unless you are intimately aware of the entirety of SNI and TLS both from a spec point of view, and the nuances of each of the major browsers behavior with regards to how they treat SNI (eg: local names, localhost, ip literals, non-routables, reserved hosts, protected hosts, etc).
Start with the default behavior in Jetty (which just uses the built-in JVM techniques for working with TLS + SNI as a server), then if you have more needs in terms of how to select a certificate, look at providing your own SniX509ExtendedKeyManager.SniSelector (but make sure to keep it up to date! you'll want to follow the code of the default implementation periodically to catch changes that happen due to various factors: major browser vendor changes in behavior, JVM changes in behavior, Java crypto roadmap changes, etc)
Related
Two-Way SSL - or mutual authentication - is typically dictated in HTTPS by the server. For example, this tutorial explains how to set up WildFly application server to require webservice clients to present a certificate during communication.
However, in our case we need to enforce Two-Way SSL on the client side. That means our client is configured with a client certificate so that it can supply the certificate during handshake. If a server we are connecting to does not ask for the certificate, we want to abort communication.
Descriptions of the SSL handshake like the diagram in the section titled "The SSL Protocol" here (a bit further down) explain how the first thing happening is selection of a cipher suite:
"1. Client hello - The client sends the server information including the
highest version of SSL it supports and a list of the cipher suites it
supports. (TLS 1.0 is indicated as SSL 3.1.) The cipher suite
information includes cryptographic algorithms and key sizes."
On Java side (more specifically: CXF in my case) , it's possible to filter cipher suites("cipherSuitesFilter") - so I thought it would be possible to limit cipher suites to those requiring mutual authentication. But I don't find any links between cipher suites and two-way SSL. For example, this page notes:
authentication algorithm - dictates how server authentication and (if
needed) client authentication will be carried out.
I'm starting to think that means the cipher suite only dictates how client authentication is done, not if client authentication is required.
That leaves me at a dead end. Is there any other way to enforce client authentication on the client side?
Right now the only solution I can think of is finding the right hook method to implement for SSL communication after the handshake has been done, checking if the connection uses client authentication and aborting if it's not. But I'd like to use any kind of common approach for, if such a thing exists.
We didn't find a better solution than the one I already mentioned in my question.
As a client, we can only check whether a connection was established using a client certificate. That does not guarantee that the server thoroughly verified the certificate, just that it requested a certificate.
Our implementation is a custom javax.net.ssl.SSLSocketFactory that extends createSocket methods to check whether javax.net.ssl.SSLSession.getLocalCertificates() returns something. If not, an exception subclass of javax.net.ssl.SSLException is thrown to abort communication.
The socket factory is set via org.apache.cxf.configuration.jsse.TLSClientParameters.setSSLSocketFactory(SSLSocketFactory).
I have a legacy java web application that makes calls to an external webservice. The provider of that service is turning off TLS1.0 support. So, I am trying to see how the application can continue to work with the service.
The options I have seen are a) use BouncyCastle JCE instead of Java JCE http://boredwookie.net/index.php/blog/how-to-use-bouncy-castle-lightweight-api-s-tlsclient/, which I guess requires code change/ recompile (we don't have the luxury of doing it) or 2) use proxy servers https://www.reddit.com/r/sysadmin/comments/48gzbi/proxy_solution_to_bump_tls_10_connection_to_tls_12/
I have tried nginx proxy - it doesn't seem to handle the switch between TLS1.0 incoming and TLS1.2 that the end server expects.
server { listen 443 ssl; server_name proxy.mydomain.com;
ssl_certificate D:/apps/openssl/proxy.mydomain.com.cert;
ssl_certificate_key D:/apps/openssl/proxy.mydomain.com.private;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!SRP;
ssl_prefer_server_ciphers on;
location / {
proxy_pass https://fancyssl.hboeck.de/;
}
This fails with a 502/ bad gateway error since https://fancyssl.hboeck.de only support TLS1.2 but works with https://www.google.com that supports TLS1.0.
I am doing this on Windows.
It's not TLSv1.2, it's lack of SNI leading to renegotiation.
First, I set up nginx (1.8.1/Windows) with a config like yours except using my own key&cert and proxying to my own test server. It worked fine, connecting from Java6 requester with TLSv1.0 and to server with TLSv1.2 (and even ECDHE-RSA-AES256GCM-SHA384, one of the 'best' ciphersuites) and returned pages just fine. I tried fancyssl.hboek.de and got 502 like you.
With wireshark I saw that nginx does not send SNI (by default) and at least using the IPv4 address 46.4.40.249 (I don't have IPv6) that server apparently hosts more than one domain because without SNI it provides a different (and expired!) certificate, for *.schokokeks.org, and after the first application data (the request) it sends an encrypted handshake (a renegotiation request -- which nginx does not honor). Testing with openssl s_client confirms that the server with SNI immediately sends the page but without it renegotiates first; repointing nginx to openssl s_server confirms that if the server requests renegotiation, receives no response, and closes nginx treats that as 502.
I would guess that Apache is renegotiating because it realizes the requested Host is not covered by the certificate -- except that it again uses the 'wrong' certificate. I haven't tried to track that part down.
Google does support TLSv1.2 (and ECDHE-RSA-AESGCM) when I connect, but even without SNI doesn't renegotiate, presumably because it's such high volume nothing else runs on www.google.com servers and there's no ambiguity. My test server doesn't have vhosts so didn't need SNI.
The nginx documentation reveals a directive proxy_ssl_server_name which can be set on to enable SNI, and then proxying to this server works.
FYI: several of the statements on that webpage are wrong, although its conclusion (if possible use TLSv1.2 with ECDHE or DHE and AES-GCM) is good.
Also, most of your ssl_ciphers string is useless, but you didn't ask about that.
ssl_ciphers HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!SRP
HIGH is an excellent start.
SEED is useless in a server used (only) by Java/JSSE client, because it's not implemented on the Java side. Even outside of Java it was pretty much used only in South Korea, where it was created as an alternative to DES or IDEA, and even there it is mostly obsoleted by ARIA which is an alternative to AES -- but is not implemented by OpenSSL and hence nginx.
aNULL is probably unneeded because JSSE disables 'anonymous' suites by default, but here it's worth it as defense in depth.
!eNULL does nothing; no eNULL suites are in HIGH, or DEFAULT, or even ALL. You can only get them explicitly or with the bizarre COMPLEMENTOFALL -- which you shouldn't.
!EXPORT !DES !RC4 do nothing; none of them are in HIGH. If instead you started from DEFAULT on older versions of OpenSSL, or from ALL, then they would be good.
!PSK is unneeded; nginx doesn't appear to configure for PSK and JSSE doesn't implement it anyway.
!RSAPSK is ignored because OpenSSL doesn't implement that keyexchange, and if it did those suites are already covered as above.
!aDH !aECDH are covered by !aNULL and thus do nothing.
!EDH-DSS-DES-CBC3-SHA is silly; there's no reason to exclude this one suite when you keep other DHE_DSS and 3DES suites.
!KRB5-DES-CBC3-SHA is ignored because OpenSSL doesn't implement Kerberos, and if it did nginx wouldn't be configured for it plus again it would be silly to exclude one suite while keeping similars.
!SRP is unneeded; like PSK nginx apparently doesn't configure and JSSE doesn't implement.
So: HIGH:!aNULL is all you need.
I am building a Java EE web application that has a component that connects to a remote server through REST. Unfortunately this server has some problems with the SSL certificates atm which isn't getting fixed until a later date.
From what I found on google is that I should disable SNI on the JVM to temporary "fix" the issue of the handshake alert error, but I don't know how you do this on Websphere Liberty Profile.
Anyone know how to do this or knows a better solution?
You should try -Djsse.enableSNIExtension=false. In Liberty, you can put that in your $servername/jvm.options
https://www.ibm.com/support/knowledgecenter/SSYKE2_7.0.0/com.ibm.java.security.component.70.doc/security-component/jsse2Docs/customization.html
jsse.enableSNIExtension system property. Server Name Indication (SNI)
is a TLS extension, defined in RFC 4366. SNI enables TLS connections
to virtual servers, in which multiple servers for different network
names are hosted at a single underlying network address. Some very old
SSL/TLS vendors might not support SSL/TLS extensions. In this case,
set this property to false to disable the SNI extension.
We run a web application with a JVM backend (Java 7 update 75; code is in Scala, but I don't believe this is relevant). We use Google for authentication via Oauth.
There have been a handful of days over the last couple of months on which we have been intermittently unable to authenticate users.
The redirect to and from Google is successful, but when we try to call the token_endpoint at https://www.googleapis.com/oauth2/v4/token to validate the authentication we sometimes get the following exception: javax.net.ssl.SSLHandshakeException: server certificate change is restrictedduring renegotiation.
This comment on another question led me to find a JDK bug that can manifest as this exception (What means "javax.net.ssl.SSLHandshakeException: server certificate change is restrictedduring renegotiation" and how to prevent it?).
My working hypothesis is:
The bug (https://bugs.openjdk.java.net/browse/JDK-8072385) means that only the first entry in the Subject Alternative Name (SAN) list is checked. The exception above is thrown when the hostname being verified is in the SAN list, but not at the top of the list.
Yesterday (27th May 2015 from ) we saw two different certificates being intermittently served from www.googleapis.com. The first (serial 67:1a:d6:10:cd:1a:06:cc) had an SAN list of DNS:*.googleapis.com, DNS:*.clients6.google.com, DNS:*.cloudendpointsapis.com, DNS:cloudendpointsapis.com, DNS:googleapis.com whilst the second (serial 61:db:c8:52:b4:77:cf:78) had a SAN list of: DNS:*.storage.googleapis.com, DNS:*.commondatastorage.googleapis.com, DNS:*.googleapis.com.
Due to the bug in the JVM, we can validate the first certificate, but the exception is thrown with the second (despite being perfectly valid) as *.googleapis.com is not the first entry in the SAN list.
The fix is in the yet to be released 7u85 (no mention of when this will be available).
I've downgraded a single node of our cluster to 7u65, but the certificate seemed to be reverted at around the time we did this (last error we saw was 22:20GMT) so it's hard to pin down an affirmative fix.
Has anyone else experienced this or something similar and have any other workaround other than downgrading (downgrading removes various other SSL/TLS checks)?
I am not really sure that your problem is related to a JVM bug.
There is a fix in Java 6 and above for CVE-2014-6457, "Triple Handshake attack against TLS/SSL connections (JSSE, 8037066)", prevents peer certificates changing during renegotiation.
Problem explanation:
A security vulnerability in all versions of the Transport Layer
Security (TLS) protocol (including the older Secure Socket Layer
(SSLv3)) can allow Man-In-The-Middle (MITM) type attacks where chosen
plain text is injected as a prefix to a TLS connection. This
vulnerability does not allow an attacker to decrypt or modify the
intercepted network communication once the client and server have
successfully negotiated a session between themselves.
However, if the potentially changed certificate is for the same identity as the last seen certificate then the connection is allowed.
Two identities are considered equal in this case:
There is a subject alternative name specified in both certificates which is an IP address and the IP address in both certificates is the same.
There is a subject alternative name specified in both certificates which is a DNS name and the DNS name in both certificates is the same.
The subject and issuer fields are present in both certificates and contain identical subject and issuer values.
In other conditions (the identity of the certificate has changed) then a javax.net.ssl.SSLHandshakeException: server certificate change is restricted during renegotiation exception is raised.
Workaround:
Disable renegotiation (not recommended) applying the following JVM argument: -Djdk.tls.allowUnsafeServerCertChange=true it disables the unsafe server certificate protection.
Disable SSLv3 in outgoing HTTPS connections, Java 7 supports TLSv1.1 and TLSv1.2 in client mode but defaults to using TLSv1 in the TLS handshake. We should use TLSv1.1 and TLSv1.2 in client mode TLS in java 7 as well. Java 8 enables TLSv1.1 and TLSv1.2 in client mode(in addition to SSLv3 and TLSv1) and uses TLSv1.2 by default in TLS handshake. If you are creating the connection programatically and setting a socket factory use TLS instead of SSL.
Anyway, update your post with your google oauth client code before calling the token_endpoint to validate the authentication to see what might be happening.
The Blog site (Client-Auth REQUESTED in GlassFish) reads:
In domain.xml, please add the following property to http-listener element
<property name="com.sun.grizzly.ssl.auth" value="want"/>
However, when adding this to my GlassFish v3 domain.xml, the existing browser client certificate is not requested. The GlassFish server is properly set up, i.e., requires client certificates with the option "client-auth-enabled" set to true.
The GlassFish bugtracker (1) mentions a different version:
* client-auth: want/need/<blank>
However, this property doesn't get accepted either.
Others have the same problem (2).
How can I enable an optional client certificate request in GlassFish? Are there alternatives?
(1) http://java.net/jira/browse/GLASSFISH-6935
(2) https://stackoverflow.com/questions/3634129/configure-glassfish-v3-client-auth-requested-to-want
Probably because it doesn't exist.
*When you deal with client certificates in HTTPS, keep in mind your HTTPS listener configurations. The SSLv3/TLS protocol allows three modes for an HTTPS socket.
* The traditional mode requires a single server certificate. An HTTPS client (typically a web browser) validates the server identity by matching the certificate to a list, or truststore, of Certificate Authorities. You probably use this mode every day during typical log-in activity.
* Another mode requires both client and server certificates. The client certificate is validated by the server side, and the server certificate is validated by the client side.
* The third mode requires a server certificate, but the client certificate is optional.
*In the real world, you want to use the same HTTPS URL whether a user is authenticated by password or certificate. This approach requires a server that supports the third, optional client certificate mode. At this writing, the GlassFish application server does not support this mode. Fortunately, the Apache Tomcat web server, supported by OpenSSO, is available as an alternative. For Reference