How do I set the TLS/SNI (https://en.wikipedia.org/wiki/Server_Name_Indication) in the Python/C++ gRPC client API?
In other words, what's the equivalent of setting the -servername in openssl s_client?
I have verified my TLS server works by using the correct flags on openssl s_client:
openssl s_client -connect "myserver.tunnel.dev:4443" -servername "myserver.tunnel.dev"
However, I wasn't able to setup the credentials correct with the Python /C++ API:
uri = "myserver.tunnel.dev:4443"
hostname = "myserver.tunnel.dev"
creds = grpc.ssl_channel_credentials(
root_certificates=dev_cert)
# root_certificates=certificate_chain)
# certificate_chain=certificate_chain)
channel = grpc.secure_channel(uri, creds,
options=(('grpc.ssl_target_name_override', hostname),)
)
This throws:
grpc._channel._Rendezvous: <_Rendezvous of RPC that terminated with (StatusCode.UNAVAILABLE, Connect Failed)>
In the ChannelOptions struct, the closest option I could find is ssl_target_name_override, which doesn't work either.
Setting options=(('grpc.ssl_target_name_override', hostname),) should work. This is the right way to override host name. In this case, it seems unnecessary as your uri host and override host are the same. You could turn on some tracing by using the environment variables listed here and see if the handshake is failing or the is there some other reason for connection failure.
Related
Note this is not a question about having apache accept inbound SSL connections.
I have an apache module that needs to make outbound SSL connections. When it attempts to, it gets this error:
Failed to send events: The OpenSSL library reported an error: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1269:
This is indicating the SSL library that apache is using doesn't know about the (valid) certificate of the server that my module is trying to connect to.
The CA cert on my ubuntu system where this is running is fine, knows about this downstream cert, openssl s_client tells me everything is ok.
How do I tell Apache2 to use ubuntu's system CA cert to make outbound connections work?
update - I did an strace -e open httpd -X to see where it was trying to load certificates from. I see apache opening libssl.so, but then I don't see it even trying to open up the usual ssl.cnf or any certificates file.
snipped useless strace output
update2: As to how I'm creating the https request - I'm making the request from inside my custom apache module. My module .so is written in Rust, so the connection code looks basically like:
in mod_mine.so:
use hyper::Client;
use hyper_tls::HttpsConnector;
use tokio_core::reactor::Core;
let mut core = Core::new()?;
let handle = core.handle();
let client = Client::configure()
.connector(HttpsConnector::new(4, &handle)?)
.build(&handle);
//actually a POST, but this gets the same error
let request = client.get("https://saas.mycompany.io".parse()?);
let result = core.run(request)?;
... //process result
I found a solution that works, though I'm not sure it is optimal.
openSSL takes the environment variable SSL_CERT_FILE. I can set this in my apache module source code.
use std::env;
let cert_file = figure_out_cert_path(); //on ubuntu: /etc/ssl/certs/ca-certificates.crt
env::set_var("SSL_CERT_FILE", cert_file);
I'm setting up Apache with several distinct SSL certificates for different domains that reside on the same server (and thus sharing the same IP address).
With Qualys SSL Test I discovered that there are clients (i.e. BingBot as of december 2013) that do not support the SNI extension.
So I'm thinking about crafting a special default web application that can gather the requests of such clients, but how can I simulate those clients?
I'm on Windows 8, with no access to Linux boxes, if that matters.
You can use the most commonly used SSL library, OpenSSL. Windows binaries are available to download.
openssl s_client -connect domain.com:443 command serves very well to test SSL connection from client side. It doesn't support SNI by default. You can append -servername domain.com argument to enable SNI.
If you are using OpenSSL 1.1.0 or earlier version, use openssl s_client -connect $ip:$port, and OpenSSL wouldn't enable the SNI extension
If you are using OpenSSL 1.1.1, you need add -noservername flag to openssl s_client.
Similar to openssl s_client is gnutls-cli
gnutls-cli --disable-sni www.google.com
You could install Strawberry Perl and then use the following script to simulate a client not supporting SNI:
use strict;
use warnings;
use LWP::UserAgent;
my $ua = LWP::UserAgent->new(ssl_opts => {
# this disables SNI
SSL_hostname => '',
# These disable certificate verification, so that we get a connection even
# if the certificate does not match the requested host or is invalid.
# Do not use in production code !!!
SSL_verify_mode => 0,
verify_hostname => 0,
});
# request some data
my $res = $ua->get('https://example.com');
# show headers
# pseudo header Client-SSL-Cert-Subject gives information about the
# peers certificate
print $res->headers_as_string;
# show response including header
# print $res->as_string;
By setting SSL_hostname to an empty string you can disable SNI, disabling this line enables SNI again.
The approach of using a special default web application simply would not work.
You can't do that because said limited clients not just open a different page, but they fail completely.
Consider you have a "default" vhost which a non-SNI client will open just fine.
You also have an additional vhost which is supposed to be open by an SNI-supporting client.
Obviously, these two must have different hostnames (say, default.example.com and www.example.com), else Apache or nginx wouldn't know which site to show to which connecting client.
Now, if a non-SNI client tries to open https://www.example.com, he'll be presented a certificate from default.example.com, which would give him a certificate error. This is a major caveat.
A fix for this error is to make a SAN (multi-domain) certificate that would include both www.example.com and default.example.com. Then, if a non-SNI client tries to open https://www.example.com, he'll be presented with a valid certificate, but even then his Host: header would still point to www.example.com, and his request will get routed not to default.example.com but to www.example.com.
As you can see, you either block non-SNI clients completely or forward them to an expected vhost. There's no sensible option for a default web application.
With a Java HTTP client you can disable the SNI extension by setting the system property jsse.enableSNIExtension=false.
More here: Java TLS: Disable SNI on client handshake
I'm trying to start my TURN server with TLS enabled. I use the following line to start the server:
daemon --user=$USER $TURN $OPTIONS --tls-listening-port 3478 --cert /root/cert_2014_11/my_domain_nl.crt --pkey /root/cert_2014_11/my_domain_nl.key --CA-file /root/cert_2014_11/PositiveSSLCA2.crt
The environment variables in there are set in the config file. The server works fine without TLS using the same startup line, but if I add the three SSL related arguments, the server still isn't reachable over TLS. I tried setting a different port for SLL instead of the standard port, but it still didn't work. Whatever I do, I can reach the server without SLL, but over TLS I can't reach it. The certificate chain I use if fine, I use it for our website as well.
I've run into this exact problem before. Have a look at the documentation for the --CA-file argument:
--CA-file <filename> CA file in OpenSSL format.
Forces TURN server to verify the client SSL certificates.
By default, no CA is set and no client certificate check is performed.
This argument is needed only when you will be verifying client certificates. It's not for the certificate chain for your server certificate.
Drop the --CA-file argument, keeping the --cert and --pkey arguments.
EDIT: FYI, the certificate file you give to the --cert option can contain the entire certificate chain (yours and your CA's).
I'm using mosquitto and the Eclipse PAHO Java client.
Everything is working fine on plain TCP sockets.
but now I want to use SSL for athentication (encryption not necessarily needed).
first I followed the instructions from
http://mosquitto.org/man/mosquitto-tls-7.html
in mosquitto client I can not publish my message without the --insecure option, means i have to
mosquitto_pub -h <server-ip> -p <port> -t "/topic1/test" -m "testmsg" --cafile ca_cert.pem --cert client.crt --key client_priv.key --tls-version tlsv1.2 --insecure
otherwise an protocol error appears on the mosquitto console, which says
1379576698: OpenSSL Error: error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown
1379576698: OpenSSL Error: error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure
1379576698: Socket read error on client (null), disconnecting.
-- insecure means not to check that the server certificate hostname matches the remote hostname.
little bit strange for me is that I'm trying to TLSbut the broker responds something with SSL.
however I am trying to enable SSL support in my java paho client,
i stick to the example here:
https://gist.github.com/sharonbn/4104301
as you can see in the example I do an
SSLContext context = SSLContext.getInstance("TLSv1")
so does it mean I am trying to connect with TLSv1, right?
unfortunately i get an
javax.net.ssl.SSLHandshakeException: message_unknown
I tried to switch to TLSv1.2 (because it has been working for me with mosquitto_pub) and changed the context by
SSLContext context = SSLContext.getInstance("TLSv1.2")
but then i get an
NoSuchAlgorithmException: Unknown protocol: TLSv1.2
i don't know on which side this should be unknown...
btw: if i do
mosquitto_pub -h <server-ip> -p <port> -t "/topic1/test" -m "testmsg" --cafile ca_cert.pem --cert client.crt --key client_priv.key --tls-version tlsv1 --insecure
the result is
1379595808: OpenSSL Error: error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
1379595808: Socket read error on client (null), disconnecting.
the same if i try it out of my java client
1379595995: OpenSSL Error: error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
1379595995: Socket read error on client (null), disconnecting.
so i think i have to use/enable tlsv1.2 on the java client side. but how?
anybody out there who can help me?
Thanks a lot in advance!
peace
There are a couple of points here.
First things first, you should look at generating the correct certificates. As the documentation says, --insecure should not be used in production so it's worth focusing on that. The examples in mosquitto-tls are very basic. If you follow that procedure you must set the commonName of your server certificate to match the hostname of the server. If you are doing testing on your local computer, use commonName=localhost. I can't stress enough that using --insecure makes using TLS basically pointless. A much better way of creating a certificate is to add some subjectAltName entries to define which hostnames and/or ip addresses are valid for that certificate. An example of generating certificates with this feature is given in https://github.com/binarybucks/mqttitude/blob/master/tools/TLS/generate-CA.sh Note that you will need mosquitto 1.2.1 for this to work properly.
Moving on to the TLS version issue. It sounds very much like your JRE doesn't support TLSv1.2. According to this question you need at least IBM JRE 6/7 or Oracle JRE/OpenJDK 7 for TLSv1.2. Try using TLSv1 everywhere to ensure that your Java code doesn't have a problem somewhere else. You can configure mosquitto to use TLSv1 by using the option tls_version tlsv1 in your config file, right where you define the server certificates.
The terms TLS and SSL are often used interchangeably. SSL shouldn't really be used any more, except when referring to old protocol versions, but it has stuck and when people say SSL they often mean TLS.
Currently my application (in C) authenticates to a web server using an SSL certificate. I'm now moving most of the funcitions (if not all) to Tcl.
I couldn't find any tutorial or example on how to do it (I'd prefere to use Tcl ::http:: but TclCurl would be fine).
Any suggestions?
Thanks
Johannes's answer is right, except if you want to provide different identities to different sites. In that case you use tls::init, which allows you to set default TLS-related options to tls::socket prior to that command being called.
package require http
package require tls
http::register https 443 ::tls::socket
# Where is our identity?
tls::init -keyfile "my_key.p12" -cafile "the_server_id.pem"
# Now, how to provide the password (don't know what the arguments are)
proc tls::password args {
return "the_pass"; # Return whatever the password is
}
# Do the secure connection
set token [http::geturl https://my.secure.site/]
# Disable the key
tls::init -keyfile {}
Note that the way of providing the password is bizarre, and I know for sure that this mechanism isn't going to be nice when doing asynchronous connections. (There's a standing Feature Request for improving the integration between the http and tls packages…)
To use https with tcl you usually use the tls package. The man page for the http package gives you an example how to do that:
package require http
package require tls
::http::register https 443 ::tls::socket
set token [::http::geturl https://my.secure.site/]
If you read the documentation of the tls package for tls::socket, you find that there are some options to pass client certificates. Combining that gives you:
::http::register https 443 [list ::tls::socket \
-cafile caPublic.pem -certfile client.pem]
You might have to specify the -password callback parameter if the certificate file is protected by a password.
Note that this solution uses the client certificate for each https (regardless of the target) request from your application.
Edit: As Donal suggested, it might be better to use tls::init than to specify it with ::http::register.
An example:
package require http
package require tls
::http::register https 443 ::tls::socket
proc ::get_cert_pass {} {
return "passw0rd"
}
# Add the options here
::tls::init -cafile caPublic.pem -certfile client.pem -password ::get_cert_pass
set tok [::http::geturl https://my.secure.site/]
To do a request, always use the last 2 line then.