We are running on jboss-eap-7.1.6, CloverDX 5.0, JDK 8
-I followed the documentation instruction for creating the keystore with a self signed certificate
-In the standalone.xml file of the jboss environment I added the keystore details to the ApplicationRealm (below in bold)
<security-realm name="ApplicationRealm">
<server-identities>
<ssl>
<keystore path="***" relative-to="jboss.server.config.dir" keystore-password="***" alias="server" key-password="***" generate-self-signed-certificate-host="localhost"/>
</ssl>
</server-identities>
<authentication>
<local default-user="$local" allowed-users="*" skip-group-loading="true"/>
<properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
</authentication>
<authorization>
<properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
</authorization>
</security-realm>
After doing this I am able to access the server console using https on port 8443. However when trying to connect via the designer I am seeing a generic error after accepting the self signed certificate (see attached)
I have confirmed that my local machine is able to telnet to port 8443 on the Clover Server. I have also confirmed that the same symptoms occur when attempting to use https on port 8080.
-I followed the documentation instruction for creating the keystore with a self signed certificate
-In the standalone.xml file of the jboss environment I added the keystore details to the ApplicationRealm (below in bold)
<security-realm name="ApplicationRealm">
<server-identities>
<ssl>
<keystore path="***" relative-to="jboss.server.config.dir" keystore-password="***" alias="server" key-password="***" generate-self-signed-certificate-host="localhost"/>
</ssl>
</server-identities>
<authentication>
<local default-user="$local" allowed-users="*" skip-group-loading="true"/>
<properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
</authentication>
<authorization>
<properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
</authorization>
</security-realm>
After doing this I am able to access the server console using https on port 8443. However when trying to connect via the designer I am seeing a generic error after accepting the self signed certificate (see attached)
I have confirmed that my local machine is able to telnet to port 8443 on the Clover Server. I have also confirmed that the same symptoms occur when attempting to use https on port 8080.
-
The error message contains an URL with an IP address. Do you use the same IP address in the "CloverDX Server URL" field in the connection dialog? And does the CN in your certificate match to the IP address?
If you have a hostname in the CN, you have to use it in the "CloverDX Server URL" as well. If you have an IP address instead of the hostname, use the same IP address as the "CloverDX Server URL".
If this does not help, go to "<workspace>/.metadata" directory on the filesystem and share your ".log" and "CloverDX.log" files with me, please. -
I created a new jks with the CN as my server IP and used server IP in the server URL field. However the same problem is still occurring.
I'm unable to find a ".metadata" directory anywhere on the file system. Are you referring to the jboss server logs? Likewise, I see no logs called CloverDX.log after doing a search for the file. -
I found the .log file on my local machine (was looking on the server) and found the No subject alternative names present error.
I was then able to get it working by adding the san option when creating the key store and keeping the host name in the CN field.
Still not sure why it wasnt working when using the IP in the CN field?
keytool -genkeypair -alias server -keyalg RSA -keystore ./serverKS.jks -ext san=ip:****** -keypass p4ssw0rd -storepass p4ssw0rd -validity 900 -dname "cn=******, ou=DX, o=Clover, c=CR" -
I dare to quote Atlassian knowledge base: No subject alternative names present is caused when accessing an application over HTTPS by using the IP address on the URL rather than the domain contained in the remote SSL certificate and the SSL certificate being fetched does not contain the Subject Alternative Name (SAN) parameter with the matching IP address as an alternative attribute. Java is very strict about enforcing that the certificate contains a SAN entry for the IP address, if that is how it's being accessed.
Source: https://confluence.atlassian.com/stashkb/no-subject-alternative-names-693896719.html
Please sign in to leave a comment.
Comments 4