In Two way SSL it is necessary that both certificates(client/server) built using same tool - ssl

I need a clarity for two-way SSL, if I Create Client self-sign certificate, using OpenSSL then save it in Pkcs12 file and Server self-sign certificate using Java keytool then save it in Jks file. Can both certificate work for two-way SSL?
Which TLS version openssl used?

The structure of a certificate is a standard and independent of a specific tool. This means it does not matter what tool is used to create certificates as long as it creates proper certificates. Also, the TLS protocol version used inside a connection has nothing to do with the certificate used for the connection and what tool was used to create the certificate.

Related

How to connect to MQTT broker using CA public certificate in java?

Background:
I have a CA root certificate (.crt) file with me and when I try to use the same certificate in MQTT.fx desktop installation tool I am able to connect to the broker successfully.
Problem:
Whereas, when I try to use the same certificate and try to connect using Java with Micronaut framework I am asked for private key, password, etc.
What did I try:
I tried converting the .crt to pem and establish connection using micronaut by using these parameters certificate-authority, certificate, private-key (Passed the same value for all)
tried to create the client certificate using the CA certificate using openssl
Expected solution:
Establishing a Connecting with MQTT broker using java either with or without Micronaut framework.
Note: All I have is the .crt certificate provided by the client.

Is a signed SSL certificate required for Worklight development?

I'm working on a demo in Worklight version 6.0 where I need to use SSL from iOS and Android to the Worklight Server.
Is there any way to use a self-signed or test certificate in the Worklight server? Or do I need to buy a certificate from one of the standard CAs even for test/demo?
I've seen references to how to import my certificate in the Android system trust store, and that looks promising, but I'm not seeing anything equivalent for iOS. There are a number of native code workarounds (which net out to disabling SSL certificate verification altogether) along with much discussion about which solution works/doesn't work (and no discussion of what still works on iOS 7 that I can find).
Is importing the certificate into the Android system truststore the best approach for development?
Is there a simple solution for iOS that allows for self-signed or test certificate that doesn't disable certificate checking entirely?
OK. I didn't find a general purpose answer, or a way to accept a particular certificate, but on iOS and Android, it is possible to disable client side certificate validation for development and test.
In Android, the default Manifest is already configured to ignore certificate validation. By default, the Application element in AndroidManifest.xml has an attribute:
android:debuggable="true"
With this setting, the client does not validate the SSL certificate presented by the server. So on Android, self-signed certs just work by default. The important thing to keep in mind is that when you move from development to production, it is important to set this attribute to false. When the attribute is set to false, the client validates the cert presented by the server, and so you will need a real signed cert for the production server. (makes sense)
In iOS, there are several proposed solutions, The one I'm using is to add the following to the end of my < App Name >.m file:
#implementation NSURLRequest(DataController)
+ (BOOL)allowsAnyHTTPSCertificateForHost:(NSString *)host
{
return YES;
}
#end
From what I gather, this is a unpublished API, and overriding it is bad form, but it works, and this is only for development, so I'm going with it.
I suppose I could be clever, and check for the hostname of my Worklight Server before blindly returning YES, but in any case, the addition of the code above does allow my app to use SSL with a self signed cert at the worklight server.
Both of these "solutions" need to be removed before the app is put into production, as they leave the app vulnerable to a man-in-the-middle attack. But for development/early test/demo they allow SSL without having to get real signed certificates.
There is a very easy way to use certificates not signed by a known CA for development and test purposes.
Note that this support does not come from Worklight. It is really up to each mobile platform to allow you to establish trust for these type of certificates or not. The recommendations given by David above, are really just workarounds to disable SSL validation, which could be a valid alternative in some cases. However, the android:debuggable flag will only get you so far as it doesn't cover certain scenarios like when directUpdate is enabled. Plus disabling all forms of SSL validation, may not be what you really want even in dev/test environments.
Here is what you can do:
First understand that pure self signed certificates won't work on iOS and Android, just because the platforms themselves do not allow you to install these type of certificates into their truststores.
Use self signed CA certificates instead. These are just as easy to create. They are the same as self signed certs except that they have the CA bit enabled to TRUE.
Beware, that self signed certs generated by some tools do not usually create certificates that are also CAs. Ensure your self signed cert is a CA as well.
OpenSSL example on how to create a self signed CA cert:
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out certificate.crt
Ensure the certificate.crt file is X.509 version 3, and has the following extension defined: basicConstraints = CA:TRUE
You can check the certificate.crt file by running the following command:
openssl x509 -in certificate.crt -text -noout
Use this certificate as your server certificate.
On iOS, e-mail your certificate.crt file or host the file on a web browser where you can manually click on it to install it. (Don't install it directly from the hosting WL server, as this only imports it into the browser space and not the device.)
Check that it gets installed by looking under Settings->General->Profiles->Configuration Profiles
Ensure iOS recognizes it and marks is as 'trusted'
On Android you can install the certificate.crt in the Android CA Store. The certificate.crt can be placed in /sdcard, and can be installed from Settings > Security > Install certificate from SD card. The certificate can also be opened by sending it as an email attachment or downloading via browser as in step 7 above. Android asks for an alias for the certificate, choose any name.
Check that it gets installed by looking under Settings -> Security -> Trusted Credentials ->User
Yes, you can achieve this by doing the following:
Create a self signed certificate that will act as a certificate authority.
Install this certificate on the iOS device (easiest way for me to do this was to host the certificate on a server and visit the link in safari and then download it). The iOS device will now trust any a server with a certificate that has been signed by this certificate authority
Create a new certificate that is signed by the certificate authority you created in step 1.
Use this newly signed certificate on your Worklight server
Currently Worklight App not work with a self-signed certificate. It is intended to be used in production, therefore it will only accept a valid CA cert.

SSL Cert Vendor Change

I am trying to prepare for the switch in the SSL certificate vendors.
For the the SSL validation, Our Tomcat web application uses a JKS file created from a DigiCert certificate ( *.cer files). Our company is now switching to VeriSign next week. Since they have already provided the new *.cer files, can I simply add the new cert ( using keytool) to the existing JKS so that it works for both certificates. I am trying to avoid any downtime during the switch and prepare the server beforehand?
Any helps will be much appreciated.
You must install the certificate onto the same keystore you created the CSR from as the private key resides there. Otherwise it will not work. Please reference the article below on instructions on how to import into a tomcat server:
https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR234&actp=search&viewlocale=en_US&searchid=1369174910074

Import Self Signed Certificates into Netty

I need to set up SSL for my Netty server for which I am planning to use a self signed certificate. I wanted to know what are the steps involved in doing so ?
Use openssl to get a .key & .csr file.
Do I need to convert the .csr file into pem ?
How do I import the the certificate in the keystore? Is that cacerts on a linux machine?
Do I also need to import the keys into the keystore?
This tutorial shows the steps for using a certificate signed by StartSSL:
http://blog.hintcafe.com/post/33709433256/https-server-in-java-using-netty-and-keystore
I think the steps can be modified for using your self-signed certificate (or you could sign it for free using StartSSL.

Using SSL Certificates on Netty

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