I have the following setup using Weblogic 12c on a Centos8 server:
There is one domain, that consists of two machines (machine0 and machine1).
Nodemanager is configured for both, and the admin console also tells me, that both nodemanagers are reachable. Both of the machines ip adresses are set in the /etc/hosts file to machine0 and machine1.
Hostname verification is disabled in the admin server, as well as in the nodemanager's properties files. So far so good.
Furthermore I'm using custom certificates in two jks stores (ID nd Trust) which have been verified to work in a different scenario (just using localhost in two "machines").
Now I create a new managed server via the admin console (doesn't matter for which machine) with hostname verification turned OFF in the SSL tab (all other necessary SSL settings are valid).
If I try to start it right after creation via the admin console (nodemanager is reachable!) the server log tells me:
<BEA-090960> <The server's SSL configuration is not available. There will potentially be SSL handshake failures.>
<BEA-090924> <JSSE has been selected by default, since the SSLMBean is not available.>
<Security> <BEA-090908> <Using the default WebLogic SSL Hostname Verifier implementation.>
Leading to:
<Info> <Management> <BEA-141298> <Could not register with the Administration Server: java.rmi.RemoteException: [Deployer:149150]An IOException occurred while reading the input.; nested exception is:
javax.net.ssl.SSLKeyException: Hostname verification failed: HostnameVerifier=weblogic.security.utils.SSLWLSHostnameVerifier,
But it also tells me, that it was able to load trusted certs from my defined Trust store:
<Security> <BEA-090169> <Loading trusted certificates from the jks keystore file /home/iffuw/Documents/keystores/TrustStore.jks.>
The only way to start the server right after creation and correct configuration in the described manner is to add this option to the "startWeblogic" script in the domain's /bin folder.
JAVA_OPTIONS="${JAVA_OPTIONS} -Dweblogic.security.SSL.ignoreHostnameVerification=true"
to disable hostname verification via a JVM argument.
Once the server booted up, I can comment out that line again, since ALL SSL settings seem to have taken effect now.
So it looks like all custom SSL settings (my custom ID and trust stores, otherwise no SSL connection to the AdminServer would be possible) are transferred at the first server start via admin console and nodemanager, but NOT the setting to ignore hostname verification.
Am I missing something here?
Related
Using Kong v.2.8.0-alpine docker version, I get SSL errors "no SNI provided by client, serving default SSL certificate" (which is the internally generated KongHQ cert). My host certificates are loaded against the /certificates endpoint with the desired SNI entries (and viewing the certificate from the admin endpoints show my certificates).
Using a springboot application (v2.6.2) or a standalone java rest client, SSL calls are successful through Kong when the server name (https://this.host.com:8443/some-endpoint) is used as the host. However, when making the same call within the Docker network by referencing https://kong:8443/some-endpoint, the call fails with a handshake failure related to SNI being missing. Viewing the java ssl:handshake debug output, the server_name extensions is present on the fqdn host configuration, but is missing when using the docker container name.
The version of Java used is 1.8_0_212 and 1.11.
I am unable to reproduce this issue with Python or curl.
Is there a way to override the Kong default certificates?
I'm trying to connect with MQ service and for ssl connection imported my certificate in cacerts file.
But when I'm running to connect, its showing below error
rc=2059 amq9503 channel negotiation failed
Do I need to create separate keystore and place my certificate in it, then point it using parameter javax.net.ssl.truststore ?
MQ error 2059 (MQRC_Q_MGR_NOT_AVAILABLE) has nothing to do with SSL.
This error means usually means you are missing a client-side SSL certificate.
# Check your certificate installation path
javax.net.ssl.keyStore=<path to key store containing just your client certificate>
javax.net.ssl.keyStorePassword=<password for that key store>
I am currently setting up a dockerized WSO Api Manager. We have got a wildcard certificates for our domain. I successfully transformed it into a java keystore and replaced the two jks files.
When I open the API manager, I get no ssl warnings and the browser marks my connection as secure.
When I try to login I get an error :
In the log files I get :
TID: [-1234] [] [2017-03-24 11:37:55,305] INFO
{org.apache.axis2.transport.http.HTTPSender} - Unable to sendViaPost
to url[https://localhost:9443/services/AuthenticationAdmin]
{org.apache.axis2.transport.http.HTTPSender}
javax.net.ssl.SSLException: hostname in certificate didn't match:
<localhost> != </*.mydomain.io/mydomain.io/*.mydomain.io>
at org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory.verifyHostName(SSLProtocolSocketFactory.java:341)
at org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory.verifyHostName(SSLProtocolSocketFactory.java:277)
It looks like the Server is trying to do SSL connections to localhost. So how can I add a matching certificate to the keystore allowing localhost access?
Many thanks!
In the api-manager.xml file , change all references of localhost to match your domain name , restart , and it should be good.
Setting
<parameter name="HostnameVerifier">AllowAll</parameter>
is a security risk , Hostname Verification is there for a reason.
Inside the axis2\axis2.xml file on the conf folder you have to change the https transportSenderto have the following line:
<parameter name="HostnameVerifier">AllowAll</parameter>
Here you can read a little more about that
Glassfish lets to set the SSL certificate nickname through its admin console as it is highlighted in the pic below:
But almost every tutorials in the web mention that it is necessary to replace all occurrences of the default SSL nickname (s1as) with the one will be used(i.e. mydomain.com) in the domain.xml file.
So what is the proper way of setting certificate nickname?
It is very likely that the admin console is just updating the domain.xml file anyway. In either case, it is good practice to avoid modifying the domain.xml file wherever possible. There is no official advice in the Security Guide for GF4 and the only mention of the certificate nickname is:
If you enable secure admin on an SSL-enabled GlassFish Server
installation, secure admin uses the existing value
as the DAS admin alias for secure admin.
https://glassfish.java.net/docs/4.0/security-guide.pdf
Changing the nickname isn't actually necessary, from a functional perspective. When you import your key/cert to the keystores you can just use the same name to replace the existing cert, which is perfectly valid.
Edit: To change alias names with the asadmin command, you can use enable-secure-admin with either --instancealias myNewAlias or --adminalias myOtherNewAlias (or both).
The default for adminalias is s1as and the default for instancealias is glassfish-instance.
http-listener-2 is the default http listener (glassfish or payara) with ssl enabled on port 8181, if you have created another change for it in the bellow command.
asadmin set "configs.config.server-config.network-config.protocols.protocol.http-listener-2.ssl.cert-nickname=yourNickName"
Im trying to add a user using Java 6 and Apache Directory API to Active Directory running on windows server 2008, but the result i get is (UNWILLING_TO_PERFORM), now i understand that it needs a secure connection and to use unicodePwd attribute to add the password, which i did, or at least tried to do.
The server admin created a certificate for the account i use when adding users, i exported it and added it to cacert in /jre/lib/security/.
I tried to see if i can just connect securely to the AD server without performing any operations, i get 2 scenarios that fail on the binding operation .bind():
1- if i connect using port 636 and use startTLS() available in ldapNetworkConnection : then i either get PROTOCOL_ERROR server will disconnect
2- if i connect using port 389 and use startTLS() available in LdapConnectionConfig i get "Failed to initialize the SSL context" and "IllegalArgumentException :TLSv1.1"
I added the trust manager but still no luck, below is the code so far.
LdapConnectionConfig config = new LdapConnectionConfig();
config.setLdapHost(IP);
config.setLdapPort(389);
TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
tmf.init((KeyStore)null);
config.setTrustManagers(tmf.getTrustManagers());
config.setName("CN=TestAdmin,CN=Users,DC=bmrk,DC=com");
config.setCredentials("P#ssw0rd");
LdapNetworkConnection ldapNetworkConnection = new LdapNetworkConnection(config);
ldapNetworkConnection.connect();
ldapNetworkConnection.startTls();
ldapNetworkConnection.bind();
// EDIT
i switched to JNDI LDAP APIs it gave me a more reasonable error, apparently the issue comes from the SSL handshake, my app isn't able to find the valid certificate, any recommendations?
Any help is really appreciated.
Thanks,
In Case anyone is interested, my only issue was in the adding the server that generated the certificate as a CA authority in the cacerts file so that the JVM can trust certificates issued by the server although it worked smoothly and perfect with JNDI ldap APIs it doesn't work with Apache Directory not sure why.
so my recommendation is to use JNDI instead of Apache Directory and make sure you export the certificate for the account used to login to Active Directory as PKCS12 and add it to the keystore.
so it's 2 certificates, 1 for the login/bind account and 1 for the server to act as a CA (Certificate Authority).
Also Java 6 support TLSv1 as a maximum security protocol which isn't the standard case with Apache LDAP, so either upgrade you Java or use JNDI.
it works perfectly with Java 7.