Is it possible to use openssl to generate the necessary certs to provide self signed certs for ibm MQ broker (version 9) and client. Or can i only use ibm's internal mechanism to generate the certs (ie. runmqckm -cert ).
Please advise.
B.
The queue manager requires a CMS format keystore that must be managed using IBM's tools. I recommend runmqakm instead of runmqckm to manage the queue manager's keystore since runmqakm is compiled C and you can run through an entire script of commands before runmqckm is done firing up its JRE.
For anything that can use a JKS, feel free to use OpenSSL, Keytool, or anything that works with x.509 certificates. This includes Broker's Java nodes, MQ File Transfer Edition agents, MQ client apps using native Java or JEE, and so on.
Related
My goal is to run a distributed NIFI cluster inside docker containers on a docker swarm. The configurations I made to the official NIFI docker image work in a way that I am able to run the cluster.
For the cluster I use a single service and each replica is a separate NIFI instance. Since this works I want to continue with security now. I started by applying a publically signed wildcard certificate to the java application using a secret (handing over the trust- and keystore). For my opinion this could be a feasable approach for most distributed java applications. But with NIFI I now got the issue that NIFI itself does not support wildcard certificates.
I am currently thinking about an approach how to run the cluster in a way that each container has its own certificate. My current idea is to run self signed certificates inside the container using a self managed internal CA which the NIFI JVMs can trust. Since I am not 100% sure if this would be the right approach to this issue I am thankful for hints and ideas.
NIFI uses some ports to do the communication and requests are issued using the HTTP/S protocol. NIFI itself runs as java application on the nodes/containers.
Apache NiFi provides a TLS Toolkit which automates much of this process for you. It can run an ephemeral or long-lived internal certificate authority (CA) which generates internal keys and uses them to create a self-signed CA certificate and sign incoming certificate signing requests (CSR). Each node that comes online can reach out to the CA service and install a properly-configured certificate in its keystore and truststore, and automatically populate the nifi.properties file with the locations and passwords for those files with a single command-line invocation. This can be configured to run at deployment time via Dockerfile, Ruby/Python/shell script, etc.
A HMAC/SHA-256 signature is calculated over the SPKI using a shared secret token value to ensure rogue/malicious services don't get issued certificates. All the certificates will be signed by the same CA cert, and this is already populated in the truststore, so each node in the cluster will trust the others. The requested CN is also populated in the SAN entries, and additional SAN entries are supported, so this is RFC 6125 compliant.
As noted above, wildcard certificates are not supported and not recommended, for a litany of reasons (some enumerated here) but also because a more secure deployment of unique certificates is made easy using the provided toolkit. There are ongoing efforts (NIFI-5443, NIFI-5398) to modify some internal cluster communications to be resilient in the face of wildcard certificates, but these are not currently available.
I need to add a trusted cert to the cacerts that come with the JRE, but I do not have control or ownership over my customer's JRE installation. Is there a way to do this through the security APIs other than to assume a file path location for the cacerts file and read it into a custom TrustManager?
I don't recommend setting a trust store globally for the JVM, unless you are running a standalone java application. Typically you can configure the SSLContext with the needed trust material supporting the certificates you need.
However, be aware that SSL in Java is one of the more annoying parts, because the smallest configuration error can give you some really strange error messages.
Previously I have had success implementing two-way SSL authentication (public or privately signed certs) using not-yet-commons-ssl, and although the library is a bit old, it is easier to use than raw Java, especially if you have to support multiple JVM versions.
You can use your own trust store and define it in JVM -D parameters for SSL.
That I always do in exact same corporate environment I have.
I'm currently investigating for a client a solution where he wants to send and receive files using sftp in Domino.
I have looked on the net for API's covering this and found one recommended more than others; JSch.
One reason for choosing this API is for its use by others including Eclipse.
What I'd like to know is:
if there're any obsticales using this Library? If so, can you recommend any other?
are there any other caveats using sftp in Domino Java?
does Domino JVM support JavaTM Cryptography Extension (JCE)?
can we use Dominos self-signed certificates here, with Dominos CA?
/Mike
1) Sending. This should work, but you will probably have to deal with the JVM's Security Manager ("/jvm/lib/security/java.policy") of Domino to get a socket, ...
2) Receiving: You probably don't want to implement a SSH server inside domino. It's much easier and more secure to use the SSH server of the host and periodicaly scoop up the inbound files via an Agent.
Dominos Self Signed SSL certificates have nothing to do with SSH as implemented by JSch.
3) The Domino JVm will probably support theJavaTM Cryptography Extension (JCE). Watch out for the supported JRE versions of Domino.
4) Generally: Are you sure, you want to implement it that way? Probably way easier are either WebServices or a REST-API, both via SSL/TLS and optionally facilitating client certificates.
See related question.
I have a PEM file provided to me and was told that it will be needed in establishing a SSL socket that connects to a c++ server for some API calls. Does anyone know how I can read in the PEM file and connect? I was also given the parapharse password.
It sounds like the PEM file is a client cert for you to use to login to the server. If it is the client cert, and it sounds like it is, you will likely need a ca cert file also to use in validating the servers certificate in order to establish a connection.
The CA certs need to go into a truststore and your client certs need to go into a keystore. In Java, both of these will be JKS (although it has limited support for PKCS12.) There are default keystore/truststore locations for the JRE as well as for each user. You can also specify external locations for these files in your code, as in the examples below. The commons-ssl library seems to be able to support PEM directly, without the need for JKS, but I haven't used it.
The default passphrase for these keystores in Java is "changeit" without the quotes.
This page shows you have to read the PEM into your keystore/truststore. Here is another example.
Once you have your truststore and keystore set up properly, you need to pass the following JSSE system properties to your JVM:
javax.net.ssl.keyStore
javax.net.ssl.keyStoreType
javax.net.ssl.keyStorePassword
javax.net.ssl.trustStore
javax.net.ssl.trustStoreType
javax.net.ssl.trustStorePassword
You may specify them as -D parameters to the JRE or, as in the examples below, programatically.
Once you finish that, heres a commons-ssl example of creating a socket. Also, heres the Java api for SSLSocket. Heres also an example that doesn't use any apache commons.
You need a library that handles SSL. As John Ellinwood noted, some frameworks (such as Java 2 SE) offers these built-in, for others you'd need to use 3rd party libraries.
C developers often use openssl directly, but it can't be said to be easy and when using C++ there are several "gotchas" that are easy to fall into.
I suggest you use a C++ network library with support for SSL, such as QT's network library, or Poco NetSSL. See here for some tutorial documentation and here for the API documentation - you probably want to take a look at initializeClient which takes a PEM file directly.
I'm new to SSL connections so here goes my question.
I have a desktop Java program in a JAR file. This JAR sends sensitive information over the internet to a remote Tomcat server. Of course I need to encrypt the data.
If I purchase an SSL cerfiticate say from Verisign, will the data sent over SSL be automatically encrypted?
I mean in my JAR, will I still need to do extra work like use Java encryption extensions API to manually encrypt my data over the SSL connection?
Thank you.
I mean in my JAR, will I still need to do extra work like use Java encryption extensions API to manually encrypt my data over the SSL connection?
Encryption will be done for you (with the Java Secure Socket Extension). Just establish your connection using https://. Maybe have a look at HTTP Client for a higher level API.
By the way, the certificate goes on the server side (unless you want to do client-authentication too in which case, well, you'll need a client certificate too).
And yes, you could use a self-signed certificate but one of the benefits of using a certificate signed by a well known Certificate Authority (CA) like Verisign, Thawte, etc is that you won't have to add it to the trust store of the client VM (unless you disable the verification mechanism).
Follow the SSL Configuration HOW-TO on how to setup https.
If your goal is just to get the encryptian, you don't need to buy a certificate. You can make your own. Buying a certificate just creates the verification chain back to verisign (or whomever) to give users a warm fuzzy that you're really who you say you are.
SSLSocket should handle most of the work for you.
All data sent over SSL is by definition encrypted, you do not need to worry about encryption at all. Also, you do not need to by a certificate to achieve that: you can issue one on your own.
If you'll set up the SSL on Tomcat and send your data over HTTPS then the encryption will be done for you. But you don't actually need to purchase a certificate if you only need encryption for your data channel, you could generate a self-signed certificate. Have a look at this page http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html on how to configure SSL for Tomcat. But note that HTTPS can be configured not to use encryption at all (at least on Apache httpd).
To answer your question, SSL implementations automatically encrypt the data. You don't need to worry about using additional encryption routines.
It might be easiest to purchase an SSL certificate because SSL implementations provide easy certification authentication using common root certificates and provide a verification service. However, you could save some money by using a self-signed certificate.
Even with a self-signed certificate, it's important to validate the signature on the server certificate from the desktop application when you connect to the server. This will prevent man in the middle attacks.
You won't have to add your self signed certificate to the store because you should be able to disable the automatic verification mechanism and use your own.