I am trying to configure rtmps using self-signed certificate, but when I try to connect via red5pfone I get an error:
*** ServerHelloDone
NioProcessor-2, WRITE: TLSv1 Handshake, length = 890
NioProcessor-2, READ: TLSv1 Alert, length = 2
NioProcessor-2, RECV TLSv1 ALERT: fatal, unknown_ca
NioProcessor-2, fatal: engine already closed. Rethrowing javax.net.ssl.SSLException: Received fatal alert: unknown_ca
NioProcessor-2, fatal: engine already closed. Rethrowing javax.net.ssl.SSLException: Received fatal alert: unknown_ca
[WARN] [NioProcessor-2] org.red5.server.net.rtmps.RTMPSMinaIoHandler - Exception caught SSL handshake failed.
Red5-0.9.1
Red5Phone-R47
I tried to follow the directions from here:
http://gregoire.org/2008/05/26/rtmps-in-red5/ and http://www.cb1inc.com/2007/05/12/creating-self-signed-certs-on-apache-tomcat-5-5/ but it did not give results.
Please help.
Self-signed certs are really difficult to use with Flash and should be avoided. I would assume that you are using "localhost", but if you are trying to access this from an external location I would suggest getting a real CA-signed certificate (there are free ones out there) and testing with that on your domain. Versions of Red5, 1.0 or greater have better support for certs, crossdomain, and ip binding; I suggest you start with one of them.
Related
Setting up Rabbitmq with SSL
TLS server: In-state certify at ssl_handshake.erl:1368 generated SERVER ALERT: Fatal - Bad Certificate
ERROR c.t.a.derived.broker.RabbitMQBroker - Received fatal alert: bad_certificate
What can cause these error?
What is the role of the common name while generating a certificate?
Probably the client doesn't trust the CA. Make sure the client has the CA available.
My application invokes a web service request. The provider of this web service is requesting for a certificate based authentication.
Unfortunately while making the handshake, the certificate is not being returned as part of the CertificateRequest step. Below is the log trace
Cert Authorities:
<Empty>
*** ServerHelloDone
Warning: no suitable certificate found - continuing without client
authentication
I have placed the keystore and the truststore using the below properties which is being picked up during the handshake (logged in the logs)
-Djavax.net.ssl.keyStore=$CMX_SSL_KEY_STORE
-Djavax.net.ssl.keyStorePassword=123456
-Djavax.net.debug=ssl
-Djavax.net.ssl.keyStoreType=pkcs12
JAVA_OPTS= JAVA_OPTS="-D$PS_TOKEN$ENV_TOKEN $LOCAL_MEM_OPTS $GC_OPTS
$CMAX_OPTS $JMX_OPTS $CMX_SSL_TRUST_STORE_OPT $MQ_OPTS
$ADDITIONAL_JVM_OPTS $LOCAL_JVM_OPTS $CMX_SSL_KEY_STORE_OPT"
I don't have a private key as part of the keystore, as the vendor who provided the certificate refused to provide the private key. As part of the keystore, I have the whole chain of the certificate, but still its not working
Error seen in the logs is as below
Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:2023)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1125)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
Need some guidance to resolve this issue
I looked at
why doesn't java send the client certificate during SSL handshake?
which is on the same problem, but the solution provided by Bruno is failing. Not able to attach the certificate to the private key using the same alias
I don't have a private key as part of the keystore
Then you don't have a keystore: you have a truststore.
as the vendor who provided the certificate refused to provide the private key.
Of course he did. None of your beeswax.
You're supposed to provide your own private key and certificate in your own keystore.
You have a serious misunderstanding here.
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'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.