We need to support 2 way SSL in our project . For this, we need to create the TLS v1.2 certificates. I am not sure how to mention the TLS version (i.e 1.2) while creating the certificate.
The certificate is independent from the TLS version. The TLS version (and ciphers) are relevant for the SSL handshake which includes the exchange of the certificate(s). The validation of the certificates is outside the SSL handshake and is thus independent from TLS version and ciphers but depends only on the certificate itself. There is a small dependency that with TLS 1.2 the acceptable signature algorithms can be send, but as long as the certificate is signed with SHA-256 (current state of the art) you are safe.
Certificates are based on x509 standard which has certificate version(Currently v3). Like Steffen explained above independent from SSL/TLS versions.
Related
I'm trying to check a specific IIS configuration, which should reject weak SSL certificates.
How would I go about creating an SSL certificate with either RC4 or DES encryption?
I've tried using openssl with the -des flag, but it seems to still create a sha256 cert.
The choice of the symmetric cipher used in TLS (i.e. RC4, DES, AES...) does not depend on the certificate. This means that any certificate you'll create can be used together with RC4, DES, ... . Instead of trying to enforce a strong cipher using the certificate you have to do this in the server configuration. See Mozilla: Security/Server Side TLS for examples on how to configure common web servers with strong ciphers.
There is a PKI with a single CA issuing all the x509 certificates in my network.
So on my network all the servers and clients possess a certificate from my CA stored in their corresponding keystore together with the private key. Each server and client has also the CA certificate in a chain file available to validate the trust chain of the peer x509 certificate when TLS mutual authentication is going on. All fine.
Let’s suppose I have now on my network two servers and two clients and I want to make sure Client_A and Server_A succeed with TLS mutual authentication using their x509 certificates, as Client_B and Server_B should do.
At the same time, I want to make sure TLS mutual authentication between Client_A and Server_B will not succeed. (Also valid between Client_B and Server_A).
How can I make the servers and clients in my network not only verifying the trust chain, but also respecting some kind of whitelist?
Maybe this is not feasible on TLS Layer, that is what I want to have clarified.
You can achieve this using any of the below 2 approaches-
Verifying client certificate at TLS layer: Create separate intermediate issuing CA for each client group. For example, for all the clients of Server_A, create a CA named Ca_Client_A. So your chain will look like rootCA -> Ca_Client_A -> client certificates. Import this Ca_Client_A in the trust-store of Server-A. Now Server_A will allow connections to the clients which has issuing ca Ca_Client_A. Similarly, you can create Ca_Client_B intermediate CA for serving client group B by server B.
Verifying client certificate at Application layer: For this, you need to write authentication logic in your application server where you need to put constraints such as allowed client certificate-serial numbers or CN name matching with keyword for successful authentication.
Hope that helps.
There isn't any way (that I know of) to do this at the TLS layer.
Most TLS libraries offer a callback option during the certificate exchange, and that would be the appropriate place to check the certificate against a list. Returning the library-specific version of failure/unacceptable will usually cause a TLS handshake failure, and no data will have been transmitted.
A lot of this depends on the server software you are using, not the TLS standard itself. Some software packages can be configured to trust certificates issued by a particular CA certificate. In your scenario, this would allow ANY certificate issued by your CA to connect to ANY server configured to trust your CA certificate. Other server software can be configured to trust a particular certificate, or certificates with a given subject (distinguished name of the certificate, subjectAltName, etc.) So, it depends on which particular "server" you're trying to connect to. Is this an Apache web server? IIS? Tomcat? The answer varies depending on what server platform we're talking about.
My server may be attached to a RSA or ECDSA certificate.
In my code I set the prtocol method as
sslmethod = SSLv23_server_method();
and setting the cipher using the SSL_CTX_set_cipher_list() API.
The problem is when the server is attached to ECDSA certificate and if I pass "RSA" cipher SSL_CTX_set_cipher_list() does not return any error though "RSA" cipher is not compatible with ECDSA certificates.
Is there any openssl API which I can use to find out if the cipher we are going to set is compatible with the certificate or with protocol or not?
Is there any openssl API which I can use to find out if the cipher we are going to set is compatible with the certificate or with protocol or not?
If you author the app and own the server, then YES, you do know what to expect. But the general case is NO, you don't know in advance and you can't query for it. You try to setup a channel and if it fails, then you try something else.
Generally speaking, there's no way to know in advance what cipher suites a server supports; or what type of public key is bound in the server's certificate. In fact, there's no way to know what protocol versions (SSLv2, SSLv3, TLS 1.0, TLS 1.1, TLS 1.2, etc) a server supports. Its the reason for RFC 7405, TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks.
In 2016/2017, about the best you can do is assume:
No SSLv2, SSLv3; only TLS 1.0 and above
Cipher suites from the collection "HIGH:!aNULL:!kRSA:!RC4:!MD5"
"!kRSA" is "no RSA key transport", and it means you can only use ephemeral key exchanges. If a server has a RSA key, then it will only be used for authentication. That is, the key will be used to sign the server's ephemeral values during key exchange so the client knows they are authentic.
I have purchased & installed Godaddy SSL certificate. When I access the site using Chrome 24ver the https padlock shows
1) encrypted with 128-bit
2) uses TLS 1.0
3) encrypted using RC4_128 with SHA1
However I read that RC4 is not safe anymore. So my question is
1) How reliable is https connection with mentioned specs
2) How do I get AES_CBC certificate?
3) I was being told that since the server is windows hosted it cannot be upgraded to 256-bit. Is it true? If not then what should I do?
Thanks
You are mixing things up. There is no RC4 certificate or AES_CBC certificate.
You certificate is signed by a certificate authority that issued it. In your case it is Godaddy. Look for Signature Algorithm property when you open details of the certificate (i.e. doubleclick on certificate file). There will probably be something like sha1RSA or sha256RSA or something similar.
RC4 is a cipher that is negotiated when establishing SSL conection with server. It depends on both parties (client and server) witch algorithm they will use. Read more here. You can set up IIS to allow or disallow these ciphers.
I'm trying to build a simple client-server application using Netty which uses SSL certificates .
I looked around and I could only find the secure chat example [here]. It uses bogus certificates.
How to do a proper implementation of SSL certificates (self-signed) in Netty?
I would recommend against self signed certificates. It's not worth the trouble. You can get signed certificate for free from StartSSL. Check out the link below on how to convert a signed certificate into PKCS12 format and use it in SSLContext to be used with Netty.
http://blog.hintcafe.com/post/33709433256/https-server-in-java-using-netty-and-keystore