Oh dear, we all need to understand trust and SSL / TLS much better - because let's be honest - we need to configure it all of the time now. Gone are the good ol' days of HTTP:// and also SSL offload, we need to be SSL conscious more and more.
From a WLS (server) perspective, trust is all about outbound capability - whether this is to internal machines or external machines. If you use the default trust store in WLS, then this is going to fall back on the java JDK cacerts (something like 
Why did that paste as a picture? [it's the new default for blogger when you are pasting more than plain text]
Anyway, back to trusts... If you need to speak to another server using SSL, you will need to trust the CA (certificate authority) that that website has signed their certificate with. Browsers do this automatically with a standard list of CAs. Therefore, testing with the browser on the web server machine does NOT test anything. You think that firing up chrome on the web server and navigating to your favourite https:// site will prove that java and therefore AIS or JDE will be fine - no - think again.
You need a couple of extra levels of testing for that kind of trust. Firstly you need to find the user that is running the java processes on the machine, you need to test with that user. I recommend firstly starting a powershell window and using wget, that is awesome for a surface test of any connection or connector that you might be struggling with using AIS. This is going to be a level 1 test, but guess what - this does not test the cacerts from java.
The next level of testing you will need to do is using the JDK on the machine. Make sure that your JDE instance (AIS or HTML) is configured for the correct JKS. You can see this in the screen grab below. This instance is using custom identity and default trust (a setup that I recommend).
If you want to see all of the CA's in the list, you can use the standard java keytool utility. Note that you can list them without a valid password, but you cannot import.
"C:\Program Files\Java\jdk1.8.0_251\bin\keytool" -list -v -keystore "C:\Program Files\Java\jdk1.8.0_251\jre\lib\security\cacerts"
Right, so you've made it this far, how can you test that the java trusts are setup properly in the JKS? Write and run a java program that uses the cacerts to validate certificates.
create a file called wget.java
import java.io.*;
import java.net.*;
public class wget {
public static void main(String[] args) throws Exception {
String s;
BufferedReader r = new BufferedReader(new InputStreamReader(new URL(args[0]).openStream()));
while ((s = r.readLine()) != null) {
System.out.println(s);
}
}
}
then compile it and run it
"C:\Program Files\Java\jdk1.8.0_251\bin\javac" wget.java
"C:\Program Files\Java\jdk1.8.0_251\bin\java" wget https://www.google.com
There you go, you can validate the entire trust config for WebLogic, by following it's config and implementing the above code.
Identity is different, this is who the server portrays itself to be, this comes from a certificate that contains private keys. The private keys allow the server to encrypt traffic in a way that only the client can validate with the public key - therefore ensuring that only a server with a valid certificate can reply. Many JDE customers load custom certificates into a separate JKS for identity purposes for the server. These certificates generally contain any aliases that the server wants to use in identifying itself. Also if you load a custom cert for custom identity, then you need to ensure that your browsers trust the CA [which could be self signed].
The final point that I would like to raise here is that a self signed certificate is just as secure as an "proper" CA created cert. It contains the same amount of encryption and can last a little longer (that is awesome)! So I recommend using self signed certificates for anything internal, worry about proper CA's when you need to go to the internet for things.
No comments:
Post a Comment