When I run NiFI 1.8 on my local machine (http://localhost:8080/nifi) I am able to interact with the application through the API using Java. I can start and stop processors, and I get a 200 response code everytime.
When I use the same code to interact with a remote NiFI instance (which uses authentication) I get a SocketException, with the message "Unexpected end of file from server"
I tried setting credentials of the HttpURLConnection but it made no difference. Is this an issue with a certificate? If it is I'm not sure how to obtain and set the correct one.
Any clues?
There are multiple ways to authenticate against NiFi. All secure instances can accept client certificates by default, so if you have a user entity configured for some identity nifi_client, you can issue a certificate with that CN and use it when invoking the API from your Java client. Generally this involves putting the key and certificate in a Java Keystore (*.jks) and having a truststore that contains the public certificate of the NiFi server. There are specific instructions for handling certificate authentication in the NiFi Admin Guide, and you can look at the NiFi CLI as an example of an authenticated client.
Related
We have a splunk instance which is exposed to internet via say https://splunk.mycompany.com
When we access the above URL browser says connection is secure meaning all certificates are ok.
Now splunk REST API service is running on port 8089. So to access splunk REST API we have to hit
https://splunk.mycompany.com:8089
Whenever we are hitting the above URL we are getting certificate issues and browser is saying "your connection is not private"
Error is: NET::ERR_CERT_AUTHORITY_INVALID
As I am still accessing the same hostname via https (and a new port) it should establish a secure connection. But why it's failing to validate certificate authority?
Edit: I have been told by the splunk team to take ther certificate of https://splunk.mycompany.com and install in the java keystore in the machine from where the REST API call is being made. They also told this is working for otheres. My question why it is even needed?
You should enable SSL on port 8089 via server.conf file.
Have a look at the Splunk Documentation here: https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/ConfigTLSCertsS2S
I need to create a Java based XML web service client which is deployed in IBM WAS server which calls web service hosted by external system. Here 2 way ssl authentication mechanism should be there.
Configuration team has already set up the below things in quality environment of client and web service appservers:
At WAS server in which my web service client exists:
server certificate in the trustStore
client certificate is available in the keystore
At App server in which actual WebService exists:
server certificate in the keyStore
client certificate is available in the trust store
Coding:
we Auto generated classes using WSDL file provided by WS provider.
called the WS method normally like there is no 2 way ssl authentication mechanism in place.
problem: we are getting a connection exception when calling web service method from WS Client.Seems we have trouble with the 2 way ssl mechanism.
Full StackTrace Image as requested:
Assumptions:
we assumed that the entire handshake process of 2 way SSL process happens automatically when the web service call is done normally from the client.
Queries:
Is our assumption correct that entire handshake process happens
automatically here especially client sending its certificate ?
Do we need to specify at code level in java any details of path of
trust Store or KeyStore before calling the web service method to enable client to send its certificate ?
If Yes for Qn 2 do we need to set below properties in code as mentioned in some reference links
before calling WS method in client:
System.setProperty("javax.net.ssl.keyStore", "path/to/your/key");
System.setProperty("javax.net.ssl.keyStorePassword", "your-keystore- password");
System.setProperty("javax.net.ssl.trustStore","path/to/your/trust/keystore");
System.setProperty("javax.net.ssl.trustStorePassword", "your-truststore-password");
Any suggestions/advice are highly welcome as we are stuck with this since few days.Its the first time we are working on web services which need 2 way SSL.
I have a couple of java servlets which need to be secured with Mutual authentication with X509 certificates. I used the information from here to
implement mutual authentication and it works fine on my machine.
Now our integration environment has BigIP for load balancing traffic to weblogic. The SSL is terminated at BigIP and it forwards the https request to weblogic using an internal certificate instead of the client's certificate it got with the original https request. So mutual auth is not working.
The BigIP team says they can put the client's certificate in the HTTP header (SSL_CLIENT_CERT), and I am not sure how to configure weblogic to read client's cert from http header.
Do I need to write a custom Identity assertion provider and configure it in weblogic?? Is this the best approach or do I have any other option?
Any help on this is greatly appreciated!!
It is necessary to configure the identity asserter if you are using two way ssl to verify the client identity
and to use it to restrict access to application.If you are using two way ssl with signed CA(Verisign etc.) it
will be only used for trust -not for authentication or any type of application access restriction.
Check below link for detail clarification on above
http://www.oracle.com/technetwork/articles/damo-howto-091164.html.
You can follow your steps for configuring the X509 Certificate Authentication for weblogic server.
Along with above you need to follow below steps
1) Make sure that BIG IP handles client certitifcate and client key which can be configured in the HTTPS monitor in BiG IP.
2) Configure the BIG-IP to insert a header named WL-Proxy-SSL: with a value of true into each request.
3) Enable weblogic proxy plugin tab in
AdminConsole —> Servers —-> [Your_Server_Name] —> Configuration [Tab]
—> General [Sub-Tab]
Click on “Advanced” Link
Check the CheckBox in this Page “WebLogic Plug-In Enabled”
Above changes will help in undersatnding the weblogic that request coming from BIG IP was initially the SSL enabled.
Check below link for configuring WL-Proxy-SSL with BIGIP
https://support.f5.com/kb/en-us/solutions/public/4000/400/sol4443.html?sr=10058313
I'm working on a Server and Client based app which require two way SSL authentication. (Client authenticates server and Server authenticate client both using SSL Certificates.)
I'm quite new to Netty and have few doubts regarding this.
Is two way authentication possible using Netty?
Can it be simply achievable by adding another SslHandler to the pipelinefactories of both server and client?
If the above is true, how can I grab the required SslHandler at the ChannelConnected() method to do the SslHandshake? And Is it possible to invoke the second handshake at the ChannelConected() method by calling the pipeline back again?
Are there any examples I could refer to regarding this?
I really appreciate any help regarding this, answers or a push in right direction.
Is two way authentication possible using Netty?
Yes
Can it be simply achievable by adding another SslHandler to the pipelinefactories of both server and client?
Yes
If the above is true, how can I grab the required SslHandler at the ChannelConnected() method to do the SslHandshake?
You need the setup the keystore and the truststore correctly when creating your SSLContext.
And Is it possible to invoke the second handshake at the ChannelConected() method by calling the pipeline back again?
From memory, client and server authentication is done in the 1st handshake.
On the client, install the client's private key in the keystore and the server's public key in the truststore.
On the server, install the server's private key in the keystore and the client's public key in the truststore.
Are there any examples I could refer to regarding this?
Here's an example I did for websockets. It only shows you how to setup the server keystore. You will have to add a truststore as the 2nd parameter of serverContext.init(kmf.getKeyManagers(), null, null);
Here's a similar example in Scala with trust store setup.
Here's a good java guide on how to setup SSLContext.
Hope this helps.
Two way authentication requires that both server and client have certificates that the other trusts. The client needs to generate a private key, store it in his keystore, and get it signed by somebody that the server's truststore trusts.
It isn't just a matter of what code you write.
SSL is a presentation layer protocol and the SSL handshake happens right after the socket connection is established and the before the application layer gets a usable socket connection. No matter what application you are using, if you have the SSL protocol layer in place then you can work over SSL.
Two way authentication is just a matter of configuration as mentioned by #EJP above. If both the parties can establish and validate each other trust chain then the handshake succeeds. Refer the netty configuration manual for configuring SSL truststores.
The scenario is around calling an external SSL SOAP web service from within Mirth. The web service is requires an SSL/TLS connection along with a client certificate.
The intention is to use the built-in SOAP Sender Destination to call the remote secure web service, and somehow include that client certificate.
I understand that you first need to install that client certificate into the Java runtime. This may be within the Java runtime's certificate store or the Jetty certstore.
The platform:
Windows 2003 SP2
Mirth 1.8
Java jre1.5.0_09
Question: what configuration steps (Mirth, JRE certificate stores, etc.) would you suggest to successfully have a Mirth SOAP Sender include a client certificate (*.cer) when calling a web service secured by SSL?
The Java runtime, or more specifically, the Sun JSSE provider, will present a client certificate if some system properties are set. You can read details in the JSSE Reference Guide, but the important properties are javax.net.ssl.keyStore and javax.net.ssl.keyStorePassword.
There are a few drawbacks to this approach. First, setting the key store password as a system property makes it accessible to any code running in that process—although this can be controlled if a SecurityManager is installed. Second, these settings will be used for any SSL sockets created through the "default" SSLContext. If you need different credentials for different endpoints, you'll need a Mirth-specific solution.
No starting point was specified in the question, but if starting from scratch, the easiest approach is to create a new Java Key Store ("JKS" format) and generate a new key pair and a CSR. After sending the CSR to the CA and getting a certificate back, import it into the same key store. That key store is ready to use.
If a certificate is already available, it is likely to be in a stored with its corresponding private key in PKCS #12 format (.p12 or .pfx file). These can be used directly by a Java application, but the javax.net.ssl.keyStoreType property will need to be set to "PKCS12"
Mirth 1.8 cannot send a client cert when calling a SOAP web service.
I'm late a bit here for this but actually there is a possibility that it could. By sending a few config parameters to the JVM you could get the underlying SOAP engine to switch to HTTPs and provide the proper certificate.
refer to this question for details on which parameters to set for configuring the VM
Java HTTPS client certificate authentication
you will notice there are quite a few things to take care of. Normally HTTPs and client authentication should "just work" once you configured your certificates appropriately. BUT there are some servers out there that are not so friendly to B2B style clients so you have to watch out.
Using JDK 6_21 and a few tweaks with the certificate I was able to get one of them servers to behave but it was long and painful on our side for something that takes about 15 minutes to configure properly on the server.
here is another question that address this very issue (client side authentication towards unfriendly servers).
Client SSL authentication causing 403.7 error from IIS