I'd like to set my dev environment in order to avoid the hostname verification in https connection: I imported successfully che certificate in cacerts but I'm getting this error
Caused by: java.io.IOException: The https URL hostname does not match the Common Name (CN) on the server certificate in the client's truststore. Make sure server certificate is correct, or to disable this check (NOT recommended for production) set the CXF client TLS configuration property "disableCNCheck" to true.
I tried to add this line to standalone.xml (inside system-properties)
<property name="org.jboss.security.ignoreHttpsHost" value="true"/>
This system property is correctly set in JVM (saw by System.getProperty) but I'm still getting the above exception: what is the way to avoid the hostname verification without edit the application code?
I don't want to use disableCNCheck because it would be a change at level code.
Related
Coverity instance details:
SA Version: 8.6
Connect: 8.7
While trying to upload defects to coverity instance, the following error is seen
Connecting to server xxx.xxx.com:9090
[ERROR] SSL solicitation failed: Server's SSL preference is "preferred" but SSL is not configured on the server.
Though we haven't configured https (ldap ssl) in our instance, cov commit defects fails with SSL error.
Is this something introduced newly in coverity connect 8.7? Or an environment settings issue?
You may have configured Coverity Connect to use SSL.
Please check SSL settings in cim.properties
grep commit.encryption <coverity-connect-install-path>/config/cim.properties
commit.encryption should not be present or set to none if you do not intend to use SSL. Alternatively open server.xml to check if SSL is enabled. Connector section is commented when SSL is disabled
$ grep -A2 'Enable this connector to add SSL' <coverity-connect-install-path>/server/base/conf/server.xml
<!-- Enable this connector to add SSL support. -->
<!--
<Connector port="****"
I am working on WebSphere clustering. Everything was working fine. But for SSL, I accidentally change protocol from SSL_TLS to TLSV1.2.
I have changed it here
Security - - SSL certificate and key management - - SSL configuration - - CellDefultsetting - QOP - protocol
And now my administrator console is not opening.
Error in logs :
CWPKI0028E: SSL handshake protocol "SSLv2" is not valid. This protocol is specified in the SSL configuration alias "CellDefaultSSLSettings" loaded from SSL configuration file "security.xml".
The extended error message is: "no such algorithm: SSLv2 for provider IBMJSSE2".
I checked security.xml in cell, but the value f SSL protocol is still SSL_TLS.
Where do I need to revert the changes done in console? Console is no more opening.
First make sure that your browser supports TLSv1.2 and is enabled. If not, try to open admin console from a different browser which supports TLSv1.2.
If you really need to disable admin security so that you can change back the SSL settings, here is a document:
http://www-01.ibm.com/support/docview.wss?uid=swg21405302
During the testing of the Travelocity sample application at Login screen, option2 OpenID, I get the following error at the client side:
0x704: I/O transport error: peer not authenticated
Any recommendation about the required steps to activate SSL protocol
support in the Travelocity sample application running under the Tomcat7?
More details from the Tomcat7 log:
SEVERE: Servlet.service() for servlet [ForwardingServlet] in context with path [/travelocity.com] threw exception [0x704: I/O transport error: peer not authenticated] with root cause
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at com.ibm.jsse2.ab.getPeerCertificates(ab.java:61)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
at ...
Thanks for assistance.
As WSO2IS contains a self-signed certificate by default, So you need to configure its certificate as a trusted certificate to the sample application. We can configure a truststore file for the Tomcat server. you can add following two java parameters in to the "catalina.sh" file in /bin directory.
export JAVA_OPTS="-Djavax.net.ssl.trustStore=<PATH_TO_TRUST_STORE_FILE> -Djavax.net.ssl.trustStorePassword=<PASSWORD>"
As an example. Please note that the PATH_TO_TRUST_STORE_FILE file must contains the WSO2 server's certificate.
If your WSO2 server's certificate's CN value is not equal to the WSO2 Server's hostname, you would be probably hit by following error as well
hostname in certificate didn't match: !=. So, you need to make sure CN is equal to hostname as well.
I'm using Spring Security for X.509 preauthentication.
To make sure the client sends its certificate per HTTP request, is it necessary to:
Modify pom.xml to set <wantClientAuth> and <needClientAuth> to true
Set Apache's SSLVerifyClient to require reference
Based on reading, the web server must tell the client-side to sends its certificate in order for the client to actually send it. I'm confused if Spring Security AND Apache configuration is required to achieve this.
Spring Security configuration has nothing to do with whether the client sends a certificate or not. That's decided at the SSL protocol level and hence by the negotiation between the client and the server. Your question is a bit unclear in that it refers to a maven pom and an Apache configuration without explaining how your system is set up. Are you running the maven Jetty plugin with an Apache server in front?
Spring Security's X.509 authentication won't work if the SSL connection doesn't terminate at the servlet container. So if you have HTTPS between the client and Apache, and a non-SSL connection from Apache to the servlet container, then the client certificate won't normally be available.
If you are using an AJP connector, then you can configure Apache to pass the certificate on to the back end using the ExportCertData option. If you aren't, you can still take the exported certificate and pass it as a request header (you'll find examples of this elsewhere on SO). You would also need to customize the Spring Security X.509 code to extract the certificate from the header, rather than the standard java property name which it uses by default.
I was wondering if I can set an activemq broker with a ssl connection with the sole purpose of encryption (similar to HTTPS considering that the client does not check the certificate).
In that sense, I've tried seting up the broker to use ssl connection, set its keystore and on.
And on the client side, I tried using the sample code from fusesource as basis but without setting the client trust store (I would like the client to accept every certificate).
With that configuration, I could not connect the client and I got the following error message in the broker's log:
2013-05-06 15:25:32,848 | ERROR | Could not accept connection :
javax.net.ssl.SSLException: No available certificate or key
corresponds to the SSL cipher suites which are enabled. |
org.apache.activemq.broker.TransportConnector | ActiveMQ Transport
Server: ssl://0.0.0.0:61617?trace=true
Is this error really because the client has not added the broker certificate to its truststore? If so, is there a way so that the client accept the connection even without a truststore?
There was an error in my SSL configuration in the broker which caused that error message. I am not sure exactly what was wrong because I have re-done the whole configuration following this tutorial and got it to run the broker without errors.
In order to get the ssl encryption but no authentication, I basically had to set my ssl connection to <transportConnector name="ssl" uri="ssl://0.0.0.0:61617?trace=true?needClientAuth=false"/>
and to either
add the certificate directly to the JVM as in Resolving javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed Error?
or create a trust manager that accept all certificates on the client as in Setting trust store programatically in ActiveMQSslConnectionFactory seems to fail