Websphere application server administration service stopped working due to SSL configuration - ssl

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

Related

coverity commit defects errors out with SSL solicitation failed: Server's SSL preference is "preferred"

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="****"

How to disable SSL in IBM Websphere 6 and its impact?

Considering the POODLE attack, I want to disable the SSLv3 in my web app deployed on IBM WebSphere 6. There are a few concerns I cant address:
1. How to disable SSL and enable TLS in WAS 6.0 and 6.1?
2. When a client hits the url of my application in browser, and the browser supports SSL, the request will be initiated with SSL. Is there such a possibility wherein end user will get a handshake exception as the WAS 6 will have SSL disabled?
3. Is there a change required in application configuration or changing web server properties will help?
You don't need to change anything in your application.
There is already fixpack provided for latest WebSphere versions - check this page Vulnerability in SSLv3 affects IBM WebSphere Application Server
For V6.1.0.0 through 6.1.0.47:
Apply Interim Fix PI28796 : Will upgrade you to IBM Java SDK Version 5.0 Service Refresh 16 Fix Pack 7 + APAR IV66111 for change to
disable SSLv3 by default.
6.0 is soo old, that I don't remember if it even supports TLS. You will have to dig in the admin console somewhere in SSL settings (the exact path might be different) Security > SSL > SSL_configuration_name and change the protocol to TLS.
If you access WebSphere via web server (Apache or IHS), then you need to disable SSLv3 on the web server instead of application server. For details see Vulnerability in SSLv3 affects IBM HTTP Server
Add the following directive to the httpd.conf file to disable SSLv3
and SSLv2 for each context that contains "SSLEnable":
# Disable SSLv3 for CVE-2014-3566
# SSLv2 is disabled in V8R0 and later by default, and in typical V7
# and earlier configurations disabled implicitly when SSLv3 ciphers
# are configured with SSLCipherSpec.
SSLProtocolDisable SSLv3 SSLv2
Stop and restart IHS for the changes to take affect.

SSL to TLS switch - httpd RHEL 5.11

I am planning to disable SSL protocol in my site and moving to the TLS secure protocol. I will be making the configuration change in httpd. Does it require any changes to the server and client certificates or credentials which are already in place?
No it doesn't. Only the supportedProtocols needs to change.

403 - Forbidden: Access is denied, certificates issue in IIS7

I have installed a renewed SSL certificate on my web server running IIS7.
After installation, I applied website binding to port 443.
My application uses client certificates too, so I have changed the SSL setting to Require 'client certificate'.
Both client and SSL server certificates are valid but still I am not able to access my application. The error I get is:
403 - Forbidden: Access is denied.
I have enabled client certificate mapping in IIS role settings also but still not getting rid of this 403 error.
I guess client certificate is not able to handshake with server certificate. Please help!
In certificate Store verified all server certificate and client cert with its authority hierarchy are available.
also cross check below settings
Application Authentication: Anonymous
Application SSL Setting: Require SSL/ Accept
ApplicationHost.config: enabled OnetoOneMapping under iisClientCertificateMappingAuthentication also added base64 certificate mapped with service accounts
Also based on my past experience we need to ensure we have SChannel registry setting as mentioned in below post.
https://support.microsoft.com/en-us/kb/2464556
Simplest workaround just discovered this today. In IIS for your application, Go to Edit Bindings and change your port number. 443 to 4431 or 44301. Any variation you want. In your client computer, type in the new URL using new port number and you will establish a fresh connection to application. Make sure you SSL Settings for IIS Application is set to "Accept" instead of "Require". This means you can click "Cancel" when the pop up asks you to select a certificate you can simply hit "Cancel" and still hit the site. No 403 Error.
Do not spend hours trying to mess with your certificate store, just simply change the port on IIS Server and you'll be fine.

Configuring Weblogic Server for X.509 Smart Card Authentication

I am running Oracle Weblogic 11g (10.3.6) and attempting to configure two-way SSL (client certificate requested and enforced). The client certificate is on a smart card.
I have enabled "basic" ssl in the weblogic server, and used keytool to import the relevant root CA certificates into the DemoTruststore.jks file. I have set the Two-way client cert behavior to Client Certs Requested and Enforced for the server.
Unfortunately, attempting to access my application causes the following:
<Certificate chain received from 127.0.0.1 - 127.0.0.1 was incomplete.>
<NO_CERTIFICATE alert was received from 127.0.0.1 - 127.0.0.1. Verify the SSL configuration has a proper SSL certificate chain and private key specified.>
<Certificate chain received from 127.0.0.1 - 127.0.0.1 was incomplete.>
The ActivClient dialog never appears to select a certificate from the Smart Card, and a pin is never requested. Therefore, I think I misconfigured something.
Help would be greatly appreciated.
Jason
Had forgotten I asked this, so I couldn't prove an answer. Here are the steps I took to set this up:
Log into the weblogic console, http://whateveryourhostnameis.com:7001/console. You'll have to know your username and password (I won't know it)
Click on the Servers link, then the name of your actual server instance. (A dev box with weblogic will probably only have one)
On the general tab, click the "SSL Listen Port Enabled". Click save.
On the SSL tab, click the Advanced arrow to open up the advanced options.
Change the "Two Way Client Cert Behavior" to "Client Certs Requested and Enforced"
Check the box for "Use JSSE SSL"
Even though the server might say a restart is not required, keep in mind it's an Oracle product and thus inherently evil. I recommend a server restart.