Develop Reference

SSL rules when client and server are hosted separately

I'm hosting a web game on github pages. It's a react app that connects to a websocket server (via wss) running off of a linux box in my living room. I've generated a self-signed certificate for the server, and github-pages already has a Let's Encrypt certificate by default. Presumably because the cert is self signed, the client refuses to connect to the "insecure" server and I am not prompted to install the certificate or anything, because the client does have it's own separate certificate. Would just buying a real certificate solve all my problems? Should I just host the website from the same server and figure out all the stuff associated with that (I realize this is probably the best answer)? What's the public opinion on having separate ssl certificates for client and server?

you can add your self signed certificate to your local truststore, but it's a little work and everyone connecting to your site would have to do it.
buying a certificate would solve this problem, because it is then signed by a trusted certificate authority which allows everyone to verify your servers identity.
on the other hand, if you move your ui to the self signed server too, the web browser will prompt (respectively warn) the user about the untrusted certificate and the user is about to say wether he wants to advance to the site or not. this would "solve" the problem too.
last, but not least. it's quite common to have ui and backend separated and therefore having separated certificates too, but not in such little applications. in a big environment definitely worth it, because it's a separation of concerns.

Is there any way to run a selfsigned java applet without lowering java security policy?

I am working on a small java applet tool, among other things to load some images from the hard disk, and upload them to the host server.
The problem is that I don't want a verified CA to sign it, and I need the Java security settings still on "high" in the Java control panel.
The applet should run on few computers, and is not publicly available.
Now when I load the HTML page, with the security settings on "high" (default/recommended), the JRE blocks this applet because it is not CA signed. Security set to "medium" works fine, but the security settings should not be lowered only for this tool.
Is there any way to sort of add this applet as a "trusted applet", allowing it to read files and connect it to the host server through a socket connection?
Thanks

Try adding yourself as a root CA on the browsers concerned.

Java servlet - Windows Authentication Token / IIS Server

Currently I have got a specific problem finding a solution and I am hoping you are able to provide
some light on the matter.
The Structure of the problem:
The task at hand is to gather a client's login credentials (token) and pass this to the servlet. However I cannot seem to find a good resource to do this. I have researched a wide variety of ways. I.e SPNEGO, WAFFLE etc..., However, these seem to require some sort of active directory by my understanding, I am trying to gather the credentials from the users local machine. A clear explanation or guidance to how I can gather the windows credentials to the servlet for my specific request would be appreciated.
Diagrams are always a better way of explaining so I will provide one if you are still confused:
Windows PC (Client) ------------------------> Java Servlet -------------------------------------> IIS Server
(windows authentication) --------------> (Get Credentials) -------------------- (Check Credentials & Authenticate)
(token) (pass credentials)
Thank you in advanced to anyone who replies, I really appreciate it!.

You are wasting your time. If you only take the credentials from the users local machine then you have no way of knowing if those credentials can be trusted. You might as well just give every user administrative access to your web application.
The reason active directory (or something like it) is required is that it is not under the control of the client and is trusted by the server. For example, when using SPNEGO, the client authenticates itself to the windows domain, the client gets a token from the windows domain that it can only get if it is authenticated, the client passes the token to the server, the server can then validate that token with the Windows domain to confirm that the client is indeed who they claim to be. (Not quite that simple but you get the idea.)
There are other ways to do this - e.g. with PKI - but they all have in common a central, trusted authentication system that the server can use to validate credentials provided by the client.

Godaddy's Code sign certificate and MIDlet

i have developed an application in java (J2ME),
and i want trusted domain for that application using goDaddy's certificate.
can i obtain it ?
let me re describe the full scenario.
i have developed an application.in which i want FILE IO operations to be done without the permission of user (for every read write, it means user will be asked only once.)
so to obtain that i want trusted domain for my application.
for that i need to sign my application using code sign certificate.
now go Daddy's certificate is not listed under Nokia 3110Classic, so i have externally added it in CA list.
but still its showing app signing option disabled.
so my question is can i obtain trusted domain using the goDaddy's code sign certificate ?

For an explanation about the MIDP security model, see answers to StackOverflow questions Application Error Occurs in Nokia 6300 and Privileged operations in netbeans mobility.
If the certificate you used to sign your MIDlet wasn't on the phone, just adding it to the phone may not be enough.
You probably need to add the goDaddy certificate to the MIDP runtime "trusted third party" security domain. Somehow. I'm not convinced that's possible on a Nokia 3110 Classic.

Godaddy certificates usually depend on a Starfield certificate. Make sure that is in place too.
Also, the app-signing might be off because you've only installed the public key.
Edit: Actually, the private key is not necessary on the box (nor desireable). I wonder if the box is missing the Starfield certificate.

Problem Using JApplet that Accesses a Database on a Web Application Using Netbeans 6.5.1

I created a JApplet using Netbeans 6.5.1 that accesses a database. When the program is run by itself, it runs perfectly. The issue is when you try to put it online using a web application in Netbeans, it will not access the database. I was told by somebody that the problem is that Java security will not allow you to do this. Is this correct? How do I fix this problem? Thanks.

As already mentioned, an unsigned applet can only make network connection to the host from which the applet originated. However, if the database is hosted on a different server than the originating applet then you will have to make the applet signed. If the application is not for production use, you can self sign the applet (not suitable in production use where the signing has to be done by a trusted Certificate Authority. Certificate authorities typically charge a fee for the service of validating their clients' credentials.) However, for testing and demo purposes, you can create a self-signed certificate. With self-signed certificates, the browser displays a warning to the user mentioning that the information given in a self-signed certificate has not been validated by a trusted third party (Certificate Authority).
For self signing the applet take a look at the following links:
http://java.sun.com/developer/onlineTraining/Programming/JDCBook/signed.html
http://www-personal.umich.edu/~lsiden/tutorials/signed-applet/signed-applet.html
The other things to keep in mind are the JDBC driver types to use. Type-1 and Type-2 drivers are not suitable to be used within applet due their dependence on native binary code. Type-3 and Type-4 are ones you should be using to connect to database from within an applet.
The best solution is to NOT make database connection from an applet (if possible) but instead use a server side application to connect to the database on behalf of the applet.

as Clint pointed out, an applet is only allowed to connect to it's origin server.
to work around this, you can sign your applet with a certificate from a root authority, but certificates cost 200-400$/year.