I have a need to monitor certificates on various remote servers. I wondered if there is a way to do with in Java. I have seen examples for monitoring with HTTPSConnection but my remote servers do not support HTTPS connection. Has anybody tried any other method like using openssl with hostname and port
Thanks
Moses
Related
So I'm trying to connect two clients in a Java application, but in a way that one client acts as a server and other client acts as a ... client. I managed to connect them locally which works perfect, but I've been researching whether I can connect a client to a server that are not on a same network (via IPv4 or IPv6). I have read that I should do port forwarding on my router server-side. I know how to port forward, but shouldn't it be possible to do without port forwarding? If I understand correctly, only server-side should be port forwarded and the server can respond to the client without the need for the client to port forward their router? So if I'm correct, another solution would be a 'global' third party server(that is port forwarded) that would connect two clients by receiving and passing information from one client to another?
I'm just learning here, so I'm sorry if this has already been answered here but I haven't found answers to all of this in one place and I'm trying to come to a conclusion.
Yes, you can access a computer from outside the network and connect to a server
You must download the (ngrok) tool on the device that contains the server and run the tool
The client will contact the server without the need to forward the ports
ngrok
Explain the use of the tool on the site with a download link
shouldn't it be possible to do without port forwarding
Yes, you can make a connection between two machines without port-forwarding.
Example: Web servers
Take for example, web servers. By default a web server sits there listening on port 80, with 80 being the port assigned by convention for HTTP.
The web client (browser or such) sends a request by trying to connect on port 80. If there are no obstacles in the way, then the connection proceeds.
Restricted port access
However, there may be an obstacle.
One common obstacle: Unix-oriented operating systems (BSD, macOS, Solaris, Linux, AIX, etc.) by convention restrict access to ports numbered under 1,024 for security reasons. The operating system blocks any incoming connections on port 80. With that security blockage in place, the web request never reaches the server.
Port-forwarding with a packet-filter tool
One way to get past this restriction is to have the web server listen on an unrestricted port, a port numbered above 1,024, up to the 64K limit, such as 8080. Then configure the packet filter tool on the server machine’s OS to do port-forwarding. The incoming request for port 80 is altered to go to port 8080 instead.
A connection is then established between the web server and the web client.
The client thinks it is talking to the server on port 80.
The server thinks the client asked for port 8080.
With the packet filter tool in the middle altering packets on-the-fly, both server and client is none the wiser about packets being altered.
You may want to configure your firewall to allow HTTP connections from outside the machine only on 80, including blocking any external requests for 8080. In this case, only packets altered from 80 to 8080 will reach your web server. Common practice is to close as many ports as possible on a server.
FYI: For encrypted HTTP (HTTPS), the conventional port is 443 rather than 80.
Not a programming issue
Notice that there is no programming issue here. As the programmer, your client software should attempt to connect on the port number as documented for the server in which you are interested. On the server-side machine, or server-side router, port-forwarding will be configured as needed. Your client programming does not care about, or even know about, any port-forwarding that may or may not be in place. Port-forwarding is a network-admin issue, and should be transparent to the programmer.
See sister sites for networking issues
As a network-admin issue, look to the sister sites such as Server Fault and Network Engineering rather than Stack Overflow.
I have server application which runs on local host and the client also runs on local host.
As of now I am using java.net.serversocket and any application which has the ip and port detail of server can listen to the port.
My requirement is to secure the ports or secure the communication between the server and client application such that only my application client (authorised) one can listen to the ports or connect to server application. The data sent to and from client and server also has to be secured.
Apologies if naming conventions are not correct. I have been searching for solution and couldn't get anything for this, all I got is how to connect and make application communicate using socket programming , but no where I got the answer as how to secure the communication.
What you need here is some sort of authentication method to authorise only your client to communicate with the server. If you are using an existing communication protocol then it might have a specification for authentication already. If you are using your own protocol then you'll have come up with your own design for authentication.
It could be as simple as the server issuing some sort of request for authentication to the client. The client would then have to provide a satisfactory response (eg a user/password) otherwise the server would close the connection.
I would recommend taking a look at how some other protocols (eg HTTP) handle authentication to get some insight and also understand potential pitfalls.
My main objective is to maintain TLS on a secure website. I'm currently running ws on an https site, the "SSL Lock" in Chrome is appearing red/broken because I am using a non-authenticated source from an https website. I need to secure the WebSocket so that the SSL Lock is preserved.
I've been searching the web for an example of how to implement wss in Java (server) and JavaScript (client), but I can't seem to find anything that I can use. I've seen a few examples of how create an SSL Server (I do have the necessary certificates for a TLS/SSL connection), but I'm not sure how to translate this to wss.
If anyone could provide an example on how to use wss from Java, I would greatly appreciate it.
A secure websocket can use a standard SSL certificate for a web server. You could do this in, for example, Tomcat or use Apache with mod_proxy_wstunnel between the browser and you Java server.
I have a Java application which communicates with a Server and exchanges short messages over SMPP connection over TCP/IP. I want to add SSL security to make the short messages secured. I am using JSMPP (Java implementation of SMPP). I want answers to following points:
Where should I add SSL certificates in the application running machine (client)? Probably I should add them to JVM. Please confirm.
I have server implementation on another machine in java which run and waits for TCP/IP connection. Where should I add the certificates on server machine ?
Do I need to change the code or the JVM will add security to the existing code ?
Where can I find a free trial SSL certificates ?
I am using Java 1.6 and JSMPP 2.1.0
Thanks
Where should I add SSL certificates in the application running machine (client)?
Probably I should add them to JVM. Please confirm.
I have server implementation on another machine in java which run and waits for TCP/IP connection. Where should I add the certificates on server machine ?
You need to generate SSL certificates by your own for your server at server side only.
Store SSL certificates at server side Java directory.
Do I need to change the code or the JVM will add security to the existing code ?
code should be changed as you will have to connect to secured server (https) and import certificates accordingly.
Where can I find a free trial SSL certificates ?
As said in 1st answer, you need to generate certificate by your own and should no rely on free SSL certificates. (I doubt even you can find and import free certificates for your site).
You can use StartSSL to generate free SSL certificates:
https://www.startssl.com/
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.