I am testing and debugging a system where application A submits a POST request to a URL when some event occurs. One of my programs, application B, must react to this event.
Application A requires that the URL uses HTTPS. I don't want to use a self-signed certificate because it may cause problems (curl complains about the self-signed certificate when I test it locally).
Letsencrypt can create a SSL certificate for free, but requires a domain. This is a problem for me because application B runs on a virtual machine. Whenever the machine is restarted, it gets a different IP address. Currently, there is no domain associated with that machine (i. e. you can only access it via a URL like http://aaa.bbb.ccc.ddd/).
Is there a way to use a non-self-signed certificate for an application without domain (i. e. one that runs on a URL like http://aaa.bbb.ccc.ddd/)? If not, what is the easiest way to make a Spring boot application (application B) support a non-self-signed SSL certificate?
There is one answer suggesting to create one's own certificate authority and installing it on all machines that access the URL. This is not an option for me because I have no control over application A.
Update 1: Application B runs on an EC2 instance in AWS.
Letsencrypt can create a SSL certificate for free, but requires a domain. This is a problem for me because application B runs on a virtual machine. Whenever the machine is restarted, it gets a different IP address.
It does not matter if the IP changes since all what is checked is the domain name. Thus, if the machine gets a new IP address you need to update the DNS to point to this new domain name.
In general the client will check if the subject/SAN of the certificate matches the domain in the URL. It is not possible to get a certificate which is generic enough to cover all the IP addresses you could get. Thus, having your own fixed domain name with a dynamic IP address behind it is the way to go if you want to use normal clients to access the site.
Related
I'm developing a Java application (launched by Tomee) which needs to call, using JaxRS, an HTTPS server with its hostname, but the hostname is not resolved by the DNS.
In practice, my application creates a VM using Openstack API, so the IP address has been dynamically allocated during the lifetime of the application (which is why it's not solved by the DNS).
But I have to call an HTTPS server running on that VM, for which the certificate was signed using a given hostname, so I MUST call it with https://hostname, and not with https://ip_address...
I am not allowed to "play" with TLS configuration, by (for example) disabling Common Name check, so the only solution I see is to be able to "intercept" a DNS resolution request, to provide the good IP address to use.
The How to override DNS in HTTP connections in Java page shows a solution using Apache HttpClient - however, our microservice was entirely built on JaxRS, and I failed to find a way to do the same thing with it.
The client used is the v3.2.2 version of org.apache.cxf:cxf-rt-rs-client, provided by the Tomee we are based on.
Thanks for your attention!
I have a situation and not sure if it has possible solution.
I have a Java Server with SSL Socket and certificates "A" & "B". I also have 2 types of clients - one with certificate "A" and another with certificate "B". However only one certificate is loaded on a server side and therefore either clients with cert. "A" can connect or only clients with cert. "B" can connect.
Is it possible to modify Java Server such that up on a connection from any client, it will determine which certificate is used ( A vs. B ) and use appropriate cert?
P.S: Please pardon my security ignorance.
Thank you.
Being able to use two server certificates on the same IP address and port is possible via the Server Name Indication (SNI) extension, which must be supported by the client and the server.
Java supports this on the client side since Java 7.
Unfortunately, this is not supported on the server side yet. This is planned for Java 8.
Meanwhile, if you do need SNI support on your server, you may be able to use another server to handle the SSL/TLS connection and forward the plain text connection to your application. Typically, this can be done with Apache Httpd (with a reverse proxy) for HTTP(S).
Alternatively, it looks like the HTTPS-SNI-Proxy project may be more flexible for other protocols (despite having HTTPS in its name). I haven't tried it, but according to its README, it looks for the SNI extension in the initial Client Hello and then forwards the entire SSL/TLS connection (without deciphering it) to another server, depending on what is configured. In your example, you would have to set up two SSLServerSockets on distinct ports (not the one you really want to listen to) and forward connections from this tool to either port depending on what the client requests with its SNI extension.
Is there a way to identify which application is using a particular certificate? Especially one issued by GTE CyberTrust.
We have different certs used by our application in making outgoing connection to other applications. I was wondering if this can be displayed in Weblogic Server Admin Console? If not can they be displayed via other methods?
I think what makes this tricky is there are many ways to "use" a certificate.
To start with a certificate can be stored in an individual keystore, or inside jre/lib/security/cacerts, on weblogic admin console configuration, or passed using java system property -Djavax.net.ssl.trustStore. It can be used by classes such as SSLSocket, or any arbitrary library that uses this class, or configured via Spring xml.
Typically an application would "use" a certificate if it made a HTTPS connection into a domain with matching CN. I would begin by searching the source code for this (eg: search for SSLSocket / HTTPS / the CN name)
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.
I have my J2EE application deployed into a JBossAS. My Application has to respond to two different hostnames (https://foo.com/myApp and https://bar.com/myApp). It is the same instance of the app serving those two hostnames.
But I don't know how to configure the keystores. I need different keystores for each hostname. Is there a way to tie a virtual host in JBoss' server.xml to a specific connector?
Or do I have to use two different IP-addresses and create a connector for each?
A solution that does not require a second IP-address would be greatly appreciated.
With SSL you have to use two different I.P. addresses if you wish to use different SSL certificates. This isn't a shortcoming in Tomcat/JBoss, it is just the reality of the protocol.
I can't remember the technical reason off the top of my head (Google knows), but it comes down to the server not being able to read the domain name until it has decoded the incoming SSL request.
To use two different keystores you will need to define two different connectors (using different I.P. addresses or ports) in the jbossweb-tomcat55.sar/server.xml file. This will get your SSL certificates working, but if you only have one I.P. your second certificate will need to be setup on a non-standard port.
two apps can share one keystore which holds two certificates. The certificate is issued for a given domain. Define the second domain as a virtual host with different domain and do not touch the server.xml. It should work this way.