We have a Java based application that connects to a web server to download a file. This Java based application is being invoked from within TIBCO which serves as a middleware. Recently, the web server is migrated to use Https certificate. So the URL would contain the Https protocol in it.
If we run the application as a standalone Java client, it works as long as I have imported the Https certificate into the Java keystore. We then moved the application onto TIBCO and installed the certificates onto the TIBCO BW. With this, we are still facing the login problems.
In the past we have noticed that we get a PEER Not Authenticated error message if the JRE cacerts keystore file is not imported with the web server certificate. But once we import it, it always worked fine. With TIBCO, we installed it in TIBCO BW. Still the issue persist.
We also have a JRE on that server where TIBCO is running. Are we expected to import the certificate into the JRE keystore as well?.
Really need your inputs as I am not familiar with TIBCO extensively. I am googling and exploring other ideas as we speak. But any pointers are definitely helpful.
thanks,
Pavan.
I am not familiar with the "peer not authenticated" error but if you wonder how to install SSL certificates in TIBCO BW, I suggest you have a look at the following tutorial (assuming you are working with BW 5.x):
https://tibcology.wordpress.com/2017/03/19/invoking-a-web-service-over-https-with-bw-5-x/
Related
previously I've used grpc C-core for .net 2.x and it was working fine, with groc running on .net core 2.2 on server side and C#, Java grpc clients, using pem files for TLS.
Now I've noticed that the new grpc-dptnet no longer supports pem files. Does that mean everything breaks? no more backwards compatibility? I was looking forward to use the new worker service in .net core 3 to rewrite my grpc windows service, without the front end knowing it, so front end continues to use pem files for TLS. But it seems to be impossible now.
So can someone please advice me..
How many types of pfx files are there? client pfx, server pfx? or just one client pfx?
How does Java grpc client make use of the pfx file to connect to grpc server, esp when server is done in grpc-dotnet and not the C core grpc.
is there a difference between the pfx cert used by IIS and the one used by grpc server? will it cause a conflict if client side pfx is used on IIS with developer SSL cert.. for the case when asp.net web appp is also running grpc service.. esp when on the same port.. then what would happen?
How do I detect disconnect for grpc? previously with grpc-C-core, I would call Connect first, then wait for connection change status.. now with httpClient, I don't think this is possible.. or am I wrong?
I'm finding the new grpc-dotnet far more confusing and difficult to understand than the original grpc C core for .net. At least that was clear how to config ports, certs (generating pem files using openssl was very easy and all that matters was the CN field). Now with the pfx file format, I'm really confused.. so please bear with me if I sound stupid..
So i have my site on hosting company, and this company support let encrypt certificate, so i generated it and now the site is running with https protocol.My server side(spring boot application web service oriented started on VPS) for this site is on another company. My questions are:
How can i use this generated certificate on my server side part,
is it possible, what should i do?
What i need to provide to the server, and all things that are needed the server to work?
When i was without the certificate everything worked perfect, but right now on the server side i get
java.lang.IllegalArgumentException: Invalid character found in method name. HTTP method names must be tokens
and in the browser i get
net::ERR_SSL_PROTOCOL_ERROR,
when I`m trying the get resources from server.
From the hosting company i can get everything connected to the certificate
It seems that you are passing HTTPs traffic to web server which "talks" in plain HTTP.
Normally SSL termination is done on software like Apache HTTPD or Nginx.
Then you configure it to act as reverse proxy to your actual Spring boot application running in JVM.
You can also configure your JVM webserver (Jetty,Tomcat .. whatever you have) to use your Let's encrypt certificate, but I have doubt that certbot will be able to easily renew them.
I am the maintainer (not programmer) of a Tomcat application which connects to a remote web server via HTTPS. I fear that the remote certificate is either not trusted or has an unknown algorithm. How can I check this?
I cannot find any traces in Tomcat logs (catalina, ...), and I have no idea how I could use keytool with it.
Is there a way I can do without writing a Java program, or is there a simple code snippet I can test with?
I think in the following link you could find something really close to what you need:
https://gist.github.com/4ndrej/4547029
Regards
You can enable ssl-debug on the java process:
Debugging SSL/TLS Connections
Basically add this to the tomcat CATALINA_OPTS
-Djavax.net.debug=all
I have an Application Client deployed on a local Glassfish 4.1 with Java 8u20 installed. Now whenever I try to start the client on the localhost (same machine) using Java Web Start it gets blocked by Java Security with the message:
Location: http://localhost:8080
Reason: The Java security settings have prevented this application from running. You may change this behavior in the Java Control Panel.
I added localhost to the Exception Site List with following entries:
file:///
http://localhost
http://127.0.0.1
http://localhost.localdomain
then I even imported the Glassfish self-signed certificate as a Trusted Certificate in the Java Control Panel. Finally I enabled Mixed code and disabled certificate revocation checks in the Control panel. But still my application gets blocked.
As the medium Security level is not available anymore, what can I do further?
If you use a javaws from a java 1.7 u25 or earlier, your application client will work.
I have the same problem with Java8u31. My application client won't start with a javaws later than u25, but if is use u25 or under it will.
So, I use u25 to start the application client, but the application runs in the java 1.8 u31 environment.
I also cannot get the exception site list to work. I starting to think their is a bug in java here.
I tried to replace the s1as certificate in glassfish per these instructions to no avail. https://blogs.oracle.com/quinn/entry/glassfish_java_web_start_and
Not sure that it is possible to have glassfish automatically sign an application client with the new security restrictions!
I have a java application that runs on client machines that receives ajax requests from web applications. Some of these web applications that would like to use the service are served only under https.
I have the java app now accepting and handling SSL requests just fine, but I must first navigate to the server in a browser and accept the cert.
What is the best method of having a 'real cert' installed as part of this java app that listens on https://localhost:my_port?
On windows, it seems I can have an installer add a self signed cert to the machines accepted list. I had also thought about getting a verified cert for thisApp.myDomain.com and then changing host files to point that address to 127.0.0.1, but changing host files seems malicious and I worry about that being picked up by anti-virus.
The 'main' application is a web based system. Some users of this web based system would like to be able to print to special printers on designated computers. The java app is to be installed on those computers, the web application then sends ajax requests to the java app, which interacts with the printers. End users need to be able to install this java service with an easy, one-click type of installer. The web app is run from a browser on the machines doing the printing, hence localhost.
As stated earlier, the web apps need to connect to the web server (currently residing with amazon) via https. The connection to the localhost print server does not need to be https for any reason other than Chrome complains about insecure content, and chrome is currently the most widely used browser by our users.
Any thoughts or suggestions?
If by "real" cert, you mean one that signed by a trusted CA, then I think that the answer is that you probably can't. I don't think a trusted CA will issue one for you.
The answer I linked to above suggests that you set up your own CA by getting a CA cert. The other alternatives are a self-signed cert for 127.0.0.1, or tweaking your DNS resolution (e.g. via the client machines' "hosts" files) so that some name with a valid cert resolves to a loopback address on your client machines.
BTW - turning off certificate verification is not the way to go. It is better to add a self-signed certificate to the trusted cert list of (for instance) the user's browser.
If I was in your situation, I think I'd change whatever it is that requires HTTPS for requests on 127.0.0.1. Either don't require HTTPS for the requests, or change the IP address to the client's own IP address.
I try to install self signet certificate on client machine - but fails. Don't remember what was the issue. So I turn off verification for certificate in client code.
You can read about it here.