I'm using Java 8, Netty 5 Alpha.
I added the certificates from Comodo to the keystore, and according to a test website suggested by my certificate provider they are installed correctly.
But if I try to connect using Firefox, Chrome, or curl, I get errors.
From curl -v I see that it gets the correct header, but then SSLv3, TLS alert, Server hello (2):. This seems to correspond with debug messages from Java:
SEND TLSv1.2 ALERT: warning, description = close_notify
WRITE: TLSv1.2 Alert, length = 32
fatal error: 80: Inbound closed before receiving peer's close_notify: possible truncation attack?
Firefox: SSL received a record that exceeded the maximum permissible length.
From openssl s_client -connect ...:
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-DES-CBC3-SHA
verify error:num=19:self signed certificate in certificate chain
SSL handshake has read 5982 bytes and written 531 bytes
I've read elsewhere about NullPointerExceptions somewhere causing internal Java security stuff to fail. But there's no clear solutions.
Related
Running this command inside wsl 2 windows delivers the below output.
Can anyone explain why there are mixed TLSv1.3 and TLSv1.2 IN and OUT and is this a potential reason as to why its unable to get local issuer certificate.
The Windows host OS is Enterprise
I have installed ca-certificates and ran update-ca-certificates
curl -v https://google.com:443/
* Trying 172.217.169.78...
* TCP_NODELAY set
* Connected to google.com (172.217.169.78) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
Are you using a network connection subject to monitoring or 'protection' such as antivirus, like one provided by a business, organization or school? If so you are probably getting a fake cert/chain from the interceptor.
Try openssl s_client -connect google.com:443 and look at the s:and i: lines under Certificate chain. (Many hosts today require SNI to respond correctly and if your OpenSSL is below 1.1.1 you need to add -servername x to provide SNI, but google is not one of them, and anyway since your curl is at least trying 1.3 it cannot be OpenSSL below 1.1.1.)
Or, if connecting from Chrome, Edge or IE (but maybe not Firefox) on the host Windows works normally, doubleclick the padlock and look at the cert chain to see if it leads to GlobalSign Root CA (as the real google does) or something else (like e.g. BlueCoat); if the latter the interceptor's root cert is installed in your host Windows store, but not the WSL system. You can export the cert from the host browser and put it in a file, and either use it manually with curl --cacert $file, or import it to the WSL system's truststore, but that depends on what system you are running in WSL which you didn't say.
Added: the mixture of TLS 1.3 and 1.2 in the logging info is probably because 1.3 uses the same record header version as 1.2 as a transition hack, with an extension that indicates it is really 1.3 only in the two Hello messages, and the callback probably doesn't deal with this.
Turns out there were missing certificates that once provided and installed it worked fine
I receive the following nginx log frequently and unable to get any suitable answer from google search. My nginx is having a valid SSL certificate.
Jul 15 08:21:58 web-lb01 WEB_LB01_443: 2016/07/15 08:21:58 [info]
5753#0: *7101 SSL_do_handshake() failed (SSL: error:140943F2:SSL
routines:SSL3_READ_BYTES:sslv3 alert unexpected message:SSL alert
number 10) while SSL handshaking, client: x.x.x.x, server: 0.0.0.0:443
Keep an eye on the Ciphers and protocols like TLS1.2,TLS1.1, TLS1.0 are enabled . SSL handshaking comprises of not only the SSL certificate but also a common set of ciphers and protocols are negotiated between the client and the server for further encryption.
The failure is intentional and is because SSLv3 is disabled. A .NET client is defaulting to using SSLv3 and it won't retry with a supported SSL version without receiving an alert before a failure.
I've got OptRenegotiate set as per http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#ssloptions, but my server is still returning an SSL handshake failure, rather than alerting handshake failure (then sending handshake failure).
Works:
$ openssl s_client -connect my.working.server:443 -ssl3
CONNECTED(00000003)
2414208:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1472:SSL alert number 40
2414208:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:656:
Fails:
$ openssl s_client -connect my.failing.server:443 -ssl3
CONNECTED(00000003)
2414208:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:656:
Sole difference:
2414208:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1472:SSL alert number 40
It's getting this alert to be sent that is the problem: I cannot seem to find a reference to it anywhere in the Apache documentation.
A .NET client is defaulting to using SSLv3 and it won't retry with a supported SSL version without receiving an alert before a failure.
That's not how SSL protocol negotiation works. The client announces the best version it is willing to support and the server then responds with the best version it can which is equal or lower to the clients version. If this fails some clients (mostly browsers) retry with a lower SSL version because they assume a broken server. But they use a new TCP connection for this, i.e. no kind of renegotiation inside the existing connection.
There is no such thing as a protocol upgrade, which is what you describe here.
TLS 1.0 needed to be enabled on the server for it to send an alert before a failure. The .NET client receives the alert, and tries again with a secure protocol i.e. not SSLv3.
I have a problem, i made a command "openssl s_client -connect server.server:143", and the error is:
CONNECTED(00000003)
140719622096768:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown proto col:s23_clnt.c:769:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 249 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
I made that because the horde connection gives an error in login.
How can i resolve this?
openssl s_client -connect server.server:143
Port 143 is plain IMAP, that is you can not talk directly TLS to this port. If you try it you will get some data back which are not TLS, and thus strange error messages will occure. If you want to have TLS you have to either use imaps (port 993) or issue a STARTTLS command. You can also use openssl for this with
openssl s_client -connect server:143 -starttls imap
From your output it might even be that you used this option but did not put it into your question (because 7 bytes from the server would match a TLS alert, but is unusually short for an IMAP greeting). If this is the case there might be lots of reasons why the connection fails and it is not possible to pin the problem down just from your description. If you get more help look at http://noxxi.de/howto/ssl-debugging.html#hdr2.2 on how you could narrow down the problem and what you should provide on information if you need help from others.
I have a need to use a self-signed (or unsigned) certificate as a certificate for an HTTPS listener for an inbound endpoint to one of my flows. I have tried several methods to generate certificates, but I always get an error when the listener attempts to read a request:
javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
Google seems to think that the bad_certificate message has something to do with the trust store. I continue to see the same error with or without the mule tls-server configuration which is supposed to define the trust store.
I've used several different mechanisms to create the certificate:
The method using keytool in the mule documentation for the HTTPS Transport
A method described for weblogic, using keytool
A method described for Apache, using openssl, which I then imported into a java keystore using keytool
A variety of other mechanisms that are mostly variations of the above.
I have tried both with and without the tls-server and tls-client elements configured, all as described in the mule documentation.
I am at my wit's end trying to determine what key types are acceptable to Mule, and what the root cause of the issue is. Any advise is appreciated.
My configurations and error logs follow (omitting various boilerplate content)
mule-config.xml
<https:connector name="connectorName">
<!-- only one key, alias 'mule' -->
<https:tls-key-store path="/opt/mule/keys/keystore.jks" keyPassword="thePassword" storePassword="thePassword"/>
<!-- I've also tried the following, same error occurs both with or without this parameter -->
<https:tls-server path="/opt/mule/keys/keystore.jks storePassword="thePassword"/>
</https:connector>
<flow name="theFlow">
<https:inbound-endpoint host="0.0.0.0" port="8081" connector-ref="connectorName"/>
<!-- stuff: not important, works with http -->
</flow>
This configuration loads correctly, but then when I attempt to post a request using the same method that works with HTTP (but using https:// instead) I get the following error, and no response back (not a 500 error, or anything, connection is just closed). This specific run is from the key I generated using the instructions on the mulesoft documentation for HTTPS Transport, but it is not any different from the error I get using any other method.
Error Listing
[ERROR] org.mule.exception.DefaultSystemExceptionStrategy - Caught exception in Exception Strategy: Received fatal alert: bad_certificate
javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:136)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1822)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1004)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.waitForClose(SSLSocketImpl.java:1571)
at com.sun.net.ssl.internal.ssl.HandshakeOutStream.flush(HandshakeOutStream.java:103)
at com.sun.net.ssl.internal.ssl.Handshaker.sendChangeCipherSpec(Handshaker.java:689)
at com.sun.net.ssl.internal.ssl.ServerHandshaker.sendChangeCipherAndFinish(ServerHandshaker.java:1279)
at com.sun.net.ssl.internal.ssl.ServerHandshaker.clientFinished(ServerHandshaker.java:1239)
at com.sun.net.ssl.internal.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:225)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:943)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1188)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:818)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:50)
at org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)
at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)
at org.mule.transport.http.HttpServerConnection.readLine(HttpServerConnection.java:219)
at org.mule.transport.http.HttpServerConnection.readRequest(HttpServerConnection.java:185)
at org.mule.transport.http.HttpMessageReceiver$HttpWorker.run(HttpMessageReceiver.java:155)
at org.mule.work.WorkerContext.run(WorkerContext.java:310)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
Finally, thanks for your time reading this far.
UPDATE
I've started to get a different stack trace, but the same error. The change? The key and the keystore now have different passwords.
javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:136)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1822)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1004)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:820)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:50)
at org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)
at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)
at org.mule.transport.http.HttpServerConnection.readLine(HttpServerConnection.java:219)
at org.mule.transport.http.HttpServerConnection.readRequest(HttpServerConnection.java:185)
at org.mule.transport.http.HttpMessageReceiver$HttpWorker.run(HttpMessageReceiver.java:155)
at org.mule.work.WorkerContext.run(WorkerContext.java:310)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
UPDATE 2
I added the key to the .../jre/lib/security/cacerts file as a trusted certificate. No change.
The method for creating a self-signed certificate shown in the Mule doc works: I've used it several times. I tried it again and it works with your configuration, except that I removed https:tls-server, which is useless.
Here are the steps I followed:
Create the keystore with: keytool -genkey -alias mule -keyalg RSA -keystore keystore.jks (I used "thePassword" for both the keystore and the key passwords).
Configured Mule like this:
<https:connector name="connectorName">
<https:tls-key-store
path="...path.../keystore.jks"
keyPassword="thePassword" storePassword="thePassword" />
</https:connector>
<flow name="theFlow">
<https:inbound-endpoint host="0.0.0.0" port="8081"
connector-ref="connectorName" />
<set-payload value="w00t" />
</flow>
Tested with:
$ curl -vk https://localhost:8081
* About to connect() to localhost port 8081 (#0)
* Trying 127.0.0.1... connected
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using ECDHE-RSA-AES256-SHA
* Server certificate:
* subject: C=Unknown; ST=Unknown; L=Unknown; O=Unknown; OU=Unknown; CN=Unknown
* start date: 2013-05-15 18:20:34 GMT
* expire date: 2013-08-13 18:20:34 GMT
* common name: Unknown (does not match 'localhost')
* issuer: C=Unknown; ST=Unknown; L=Unknown; O=Unknown; OU=Unknown; CN=Unknown
* SSL certificate verify result: self signed certificate (18), continuing anyway.
> GET / HTTP/1.1
> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: localhost:8081
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Wed, 15 May 2013 11:24:24 -0700
< Server: Mule Core/3.4.0
< X-MULE_SESSION: rO0ABXNyACNvcmcubXVsZS5zZXNzaW9uLkRlZmF1bHRNdWxlU2Vzc2lvbi7rdtEW7GGKAwAEWgAFdmFsaWRMAA1mbG93Q29uc3RydWN0dAAmTG9yZy9tdWxlL2FwaS9jb25zdHJ1Y3QvRmxvd0NvbnN0cnVjdDtMAAJpZHQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAD3NlY3VyaXR5Q29udGV4dHQAJ0xvcmcvbXVsZS9hcGkvc2VjdXJpdHkvU2VjdXJpdHlDb250ZXh0O3hwAXB0ACRhYjcwZTY0OS1iZDhjLTExZTItOWU5Yy1mZjdmMDIxMmE5MmZwc3IAJWphdmEudXRpbC5Db2xsZWN0aW9ucyRTeW5jaHJvbml6ZWRNYXAbc/kJS0s5ewMAAkwAAW10AA9MamF2YS91dGlsL01hcDtMAAVtdXRleHQAEkxqYXZhL2xhbmcvT2JqZWN0O3hwc3IAJG9yZy5tdWxlLnV0aWwuQ2FzZUluc2Vuc2l0aXZlSGFzaE1hcJ3R2e9nRc4AAwAAeHB3DD9AAAAAAAAQAAAAAHhxAH4ACXh4
< X-MULE_ENCODING: UTF-8
< LOCAL_CERTIFICATES: [Ljava.security.cert.X509Certificate;#1c5e22a
< Content-Type: text/plain
< Content-Length: 4
< Connection: close
<
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
w00t
Hopefully this helps someone else. I'm running Mule EE 3.5.0 with jdk1.6.0_45. The command listed above would not generate a compatible keystore. The keystore was fine when running in studio but would not work on the standalone ESB.
I reviewed the keystore used on the mule-security-example3.5.0 application and found differences. I used KeyStore Explorer to create a keystore that had these attributes
Size: 1024
Version: 1
Alg: MD5 with RSA
Perhaps there is something off with the configuration on my instance of Mule EE; if someone could point me in the right direction I would appreciate it. Using a key with the above attributes will work with EE 3.5.0 which was downloaded from the customer portal this week.