We are using Play WS SSL firsttime and play.ws.ssl.loose.acceptAnyCertificate: 'true' config which intends to be for disabling Hostname Verification.
But for some reason I see , it still does the host verification and I see the following warnings.
August 3rd 2017, 15:02:25.084 *** ClientKeyExchange, DH
August 3rd 2017, 15:02:25.083 *** Certificate chain
August 3rd 2017, 15:02:25.083 ***
August 3rd 2017, 15:02:25.083 Warning: no suitable certificate found - continuing without client authentication
August 3rd 2017, 15:02:25.083 0080: 72 70 72 69 73 65 43 41 30 31 rpriseCA01
August 3rd 2017, 15:02:25.083 [read] MD5 and SHA1 hashes: len = 4
August 3rd 2017, 15:02:25.083 0000: 0E 00 00 00 ....
August 3rd 2017, 15:02:25.083 <Empty>
August 3rd 2017, 15:02:25.083 *** ServerHelloDone
From my understanding,
play.ws.ssl.loose.acceptAnyCertificate: 'true' --> Strict validation
play.ws.ssl.loose.acceptAnyCertificate: 'false' --> Loose Validation
When we set the flag to false , it was able to identity server cert from keystore and does cert validation and other checks, also the handshake was happening as expected.
Where as when we set the loose config with flag true, it's NOT able to identify the server cert and throws no suitable certificate found warning and handshake fails.
For me it doesn't make any sense as it was working in the strict case but fails in the loose case which is strange behaviour.
I can say when the flag is set to true, play uses JDK's SSLEngine implementation but some other implementation in case the flag is false
Any ideas ?
Thanks
Suresh
play.ws.ssl.loose.acceptAnyCertificate: 'true' will disable certificate validation, and that is something you should not do unless you understand what are the implications (read Play Framework - Loose Options for more information).
To disable hostname verification, use this instead:
play.ws.ssl.loose.disableHostnameVerification=true
Related
I have deployed openshift(okd) 3.11 using : https://github.com/openshift/openshift-ansible/tree/release-3.11
I would want to extend the validity of all the certificates to 5 years or more.
I have tried set following variables in the inventory:
openshift_hosted_registry_cert_expire_days=1825
openshift_ca_cert_expire_days=1825
openshift_master_cert_expire_days=1825
etcd_ca_default_days=1825
and i have run the re-deploy certificate play referring to https://docs.openshift.com/container-platform/3.11/install_config/redeploying_certificates.html#redeploying-all-certificates-current-ca
ansible-playbook -i openshift-ansible/playbooks/inventory.ini openshift-ansible/playbooks/redeploy-certificates.yml
After the completion of above command, i see many of the certificates getting updated to 5 years(1825 days) validity, but kublet-server, kublet-client certificates remain default as original i.e 1 year
master-228-rak.167.254.xx.xxx.nip.io - /etc/origin/node/certificates/kubelet-client-2020-11-05-22-07-35.pem
Validity
Not Before: Nov 5 22:03:00 2020 GMT
Not After : Nov 5 22:03:00 2021 GMT
master-228-rak.167.254.xx.xxx.nip.io - /etc/origin/node/certificates/kubelet-server-2020-11-05-22-10-56.pem
Validity
Not Before: Nov 5 22:06:00 2020 GMT
Not After : Nov 5 22:06:00 2021 GMT
node1.167.254.xx.xxx.nip.io - /etc/origin/node/certificates/kubelet-client-2020-11-05-22-10-54.pem
Validity
Not Before: Nov 5 22:06:00 2020 GMT
Not After : Nov 5 22:06:00 2021 GMT
node1.167.254.xx.xxx.nip.io - /etc/origin/node/certificates/kubelet-server-2020-11-05-22-10-56.pem
Validity
Not Before: Nov 5 22:06:00 2020 GMT
Not After : Nov 5 22:06:00 2021 GMT
How can i renew these certificates to have desired value as certificate validity?
These certificates are always generated for one year and are automatically rotated. You can force redeployment by redeploying a new CA by using the -e openshift_redeploy_openshift_ca=true flag as described in the documentation:
Redeploying Node Certificates
By default, node certificates are valid for one year. OKD automatically rotates node certificates when they get close to expiring. If automatic approval is not configured, you must manually approve the certificate signing requests (CSRs).
If you need to redeploy certificates because the CA certificate was changed, you can use the playbooks/redeploy-certificates.yml playbook with the -e openshift_redeploy_openshift_ca=true flag. See Redeploying All Certificates Using the Current OpenShift Container Platform and etcd CA for details. When running this playbook, the CSRs are automatically approved.
As far as I know, since this is an automatic process, you cannot change the validity period to be different from 1 year. Make sure you are using openshift_master_bootstrap_auto_approve=true to make the renewal automatic.
I am trying to configure our IIS to serve https over the following websites :
mywebsite
mywebsite.default.corporate.domain
servername/mywebsite
I set up 2 IIS websites hosted on this server.
One is the default and hosts various services, which means that some random bindings are activated (net.pipe, net.msmq, net.tcp), plus http and https.
The other one is mywebsite with 4 bindings : mywebsite and mywebsite.default.corporate.domain both over http and https.
I have generated a certificate in p12 format, with both mywebsite, mywebsite.default.corporate.domain and servername as subject alternative name, imported it in local computer personal certificates, and this is the certificate I am using for all 3 https binding.
I set the friendly name to *mywebsite and I edited the https bindings to match each expected domain.
Both mywebsite and servername/mywebsite work great, but mywebsite.default.corporate.domain shows an invalid certificate in chrome. When I check the details, the only subject alternative name is servername, even though the public key matches the one I get with the other two valid pages.
Following various questions and answers, I tried to set the IP adress in the bindings, tried the certutil -repairestore command and numerous IIS resets. I also tried to split the websites for mywebsite and mywebsite.default.corporate.domain.
If anyone has a suggestion, I am completely at loss here and spent way too much time on this already. I am using cutting edge technology (IIS 7 on Windows Server 2008 R2).
Thanks !
Edit 1 : SSL Diagnostics Tool report as requested (anonymised as per company policy, sorry) :
System Time : Tuesday, June 02, 2020 2:20:52 PM Romance Standard Time
Processor Architecture : x64
OS : Microsoft Windows NT 6.1.7601 Service Pack 1
Microsoft Internet Information Services 7.5
SERVER SSL PROTOCOLS
PCT 1.0 : Enabled
SSL 2.0 : Enabled
SSL 3.0 : Enabled
TLS 1.0 : Enabled
SChannel EventLogging : 1 (hex)
-----
[W3SVC/1]
ServerComment : Default Web Site
ServerAutoStart : True
ServerState : Started
BINDING : http *:80:
BINDING : net.tcp 808:*
BINDING : net.pipe *
BINDING : net.msmq localhost
BINDING : msmq.formatname localhost
[W3SVC/2]
ServerComment : mywebsite
ServerAutoStart : True
ServerState : Started
BINDING : http 184.11.52.120:80:mywebsite
BINDING : https 184.11.52.120:443:mywebsite
SSLCertHash : 8111C2E82C5AD2C3E556D5D523BE8C43C4AC46BB
SSL Flags :
Testing EndPoint : 184.11.52.120:443 - Success
#CertName : *mywebsite
#Version : 3
#You have a private key that corresponds to this certificate.
#Signature Algorithm : sha256RSA
#Key Exchange Algorithm : RSA-PKCS1-KeyEx Key Size : 2048
#Subject : CN=servername.default.corporate.domain, OU=STAR, O=MYCOMPANY, L=Paris, S=Ile de France, C=FR
#Issuer : CN=COMP UniPass Server Authentication 2016 CA, O=MYCOMPANY
#Validity : From Friday, May 29, 2020 6:04:08 PM To Tuesday, July 30, 2024 6:04:08 PM
#Serial Number : 4630C58DA21F1A05A8B348255FD0B168DDF104C3
DS Mapper Usage : Disabled
Archived : False
#Basic Constraints : Subject Type=End Entity, Path Length Constraint=None
#Authority Key Identifier : KeyID=fe 3b 7f 76 62 f8 80 36 04 95 8f 34 0a e1 6d af 72 31 6a df
#Authority Information Access : [1]Authority Info Access: Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2), Alternative Name=URL=http://unipass.mycompany.com/ca/ServerAuthentication2016.crt
#Subject Alternative Name : DNS Name=servername.default.corporate.domain, DNS Name=servername, DNS Name=staruat, DNS Name=staruat.default.corporate.domain, DNS Name=mywebsite.default.corporate.domain, DNS Name=mywebsite
#Enhanced Key Usage : Client Authentication (1.3.6.1.5.5.7.3.2), Server Authentication (1.3.6.1.5.5.7.3.1), Secure Email (1.3.6.1.5.5.7.3.4)
#CRL Distribution Points : [1]CRL Distribution Point: Distribution Point Name:Full Name:URL=ldap://ldap.unipass.mycompany/CN=ServerAuthentication2016,OU=UniPass,O=COMP?certificateRevocationList, [2]CRL Distribution Point: Distribution Point Name:Full Name:URL=http://http.unipass.mycompany/?crlname=ServerAuthentication2016, [3]CRL Distribution Point: Distribution Point Name:Full Name:URL=http://unipass.mycompany.com/crl/ServerAuthentication2016.crl
#Subject Key Identifier : 86 dd 98 41 1c db fc 08 af d1 e8 5b 04 a8 c0 ba 93 be 6f 2a
#Key Usage : Digital Signature, Non-Repudiation, Key Encipherment (e0)
Certificate verified.
[W3SVC/3]
ServerComment : mywebsite.default.corporate.domain
ServerAutoStart : True
ServerState : Started
BINDING : https 184.11.52.120:443:mywebsite.default.corporate.domain
SSLCertHash : 8111C2E82C5AD2C3E556D5D523BE8C43C4AC46BB
SSL Flags :
Testing EndPoint : 184.11.52.120:443 - Success
#CertName : *mywebsite
#Version : 3
#You have a private key that corresponds to this certificate.
#Signature Algorithm : sha256RSA
#Key Exchange Algorithm : RSA-PKCS1-KeyEx Key Size : 2048
#Subject : CN=servername.default.corporate.domain, OU=STAR, O=MYCOMPANY, L=Paris, S=Ile de France, C=FR
#Issuer : CN=COMP UniPass Server Authentication 2016 CA, O=MYCOMPANY
#Validity : From Friday, May 29, 2020 6:04:08 PM To Tuesday, July 30, 2024 6:04:08 PM
#Serial Number : 4630C58DA21F1A05A8B348255FD0B168DDF104C3
DS Mapper Usage : Disabled
Archived : False
#Basic Constraints : Subject Type=End Entity, Path Length Constraint=None
#Authority Key Identifier : KeyID=fe 3b 7f 76 62 f8 80 36 04 95 8f 34 0a e1 6d af 72 31 6a df
#Authority Information Access : [1]Authority Info Access: Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2), Alternative Name=URL=http://unipass.mycompany.com/ca/ServerAuthentication2016.crt
#Subject Alternative Name : DNS Name=servername.default.corporate.domain, DNS Name=servername, DNS Name=staruat, DNS Name=staruat.default.corporate.domain, DNS Name=mywebsite.default.corporate.domain, DNS Name=mywebsite
#Enhanced Key Usage : Client Authentication (1.3.6.1.5.5.7.3.2), Server Authentication (1.3.6.1.5.5.7.3.1), Secure Email (1.3.6.1.5.5.7.3.4)
#CRL Distribution Points : [1]CRL Distribution Point: Distribution Point Name:Full Name:URL=ldap://ldap.unipass.mycompany/CN=ServerAuthentication2016,OU=UniPass,O=COMP?certificateRevocationList, [2]CRL Distribution Point: Distribution Point Name:Full Name:URL=http://http.unipass.mycompany/?crlname=ServerAuthentication2016, [3]CRL Distribution Point: Distribution Point Name:Full Name:URL=http://unipass.mycompany.com/crl/ServerAuthentication2016.crl
#Subject Key Identifier : 86 dd 98 41 1c db fc 08 af d1 e8 5b 04 a8 c0 ba 93 be 6f 2a
#Key Usage : Digital Signature, Non-Repudiation, Key Encipherment (e0)
Certificate verified.
BINDING : http 184.11.52.120:80:mywebsite.default.corporate.domain
-----
Edit 2 : Apparently the issue in intermitent which is even more incomprehensible/worrying to me.
Edit 3 : I have a feeling it is actually a client error. When the certificate is valid, the Certification Path is not the same as when the certificate is invalid. I am not sure this is possible but there seems to be 2 different corporate root certificate that chrome chooses from to validate my website certificate, one of which allows the good alias, and the other does not. I will contact the ssl support.
Edit 4 : Wanted to wait a bit to confirm that the issue disappeared for good, and it did. I do not have a good explanation but I think there was a configuration issue on our intranet maybe because my company does some weird man in the middle proxying and it might have been wrong for a while. I really do not have the level of expertise to understand what went wrong so this is yet another useless question on stackoverflow, my deepest sympathies if you end up on this question and expect some help...
I did a "renew Cert" on one of my Enterprise subCAs, and it's totally messed up my results on Enterprise PKI in MMC. In the Certificate Authority snapin, there are now two certs (Certificate #0 and #1). The AIA (ldap) is showing "Unable to Download", with the "original CN=". The CDP (ldap) location has a (1) on it, as does the DeltaCRL. Every time I renew the revocation, it makes both the original cert's crl and a (1). The CDP/DeltaCRL (http) also both show "unable to download", even though the files exist in the directory. The only AIA location that shows OK is the http location.
I need to get rid of the old CA cert (the #0), I'll re-push the new one out via a GPO once this all is resolved. I tried to remove the AIA via ADSIEdit, and then republish it via "certutil -dspublish" but that gives me a 0x80070057 (WIN32: 87 ERROR_INVALID_PARAMETER) error. Trying to connect to the Configuration of the specific CA via ADSIEdit says "server is not operational". In ADSIEdit CN=CDP there are multiple entries, the normal "CA", a "CA-1", and a "CA-1(1)".
This is in our "Test" environment (luckily), but I need to get a proper process sorted out as I need to do this in two other forests. I'm actually tempted to just totally rebuild a new CA in the other zones instead of fighting with all of this.
All I'm trying to do is re-issue a subCA's cert, and get it to work correctly and report healthy in Enterprise PKI!
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\OMNI-
TST-CERTAUTH-01-CA-1\CRLPublicationURLs:
CRLPublicationURLs REG_MULTI_SZ =
0: 65:C:\windows\system32\CertSrv\CertEnroll\%3%8%9.crl
CSURL_SERVERPUBLISH -- 1
CSURL_SERVERPUBLISHDELTA -- 40 (64)
1: 79:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10
CSURL_SERVERPUBLISH -- 1
CSURL_ADDTOCERTCDP -- 2
CSURL_ADDTOFRESHESTCRL -- 4
CSURL_ADDTOCRLCDP -- 8
CSURL_SERVERPUBLISHDELTA -- 40 (64)
2: 134:http://pki.omni.phish/CertEnroll/%3%4%9.crl
CSURL_ADDTOCERTCDP -- 2
CSURL_ADDTOFRESHESTCRL -- 4
CSURL_ADDTOIDP -- 80 (128)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\OMNI-
TST-CERTAUTH-01-CA-1\CACertPublicationURLs:
CACertPublicationURLs REG_MULTI_SZ =
0: 1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt
CSURL_SERVERPUBLISH -- 1
1: 3:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11
CSURL_SERVERPUBLISH -- 1
CSURL_ADDTOCERTCDP -- 2
2: 32:http://%1/ocsp
CSURL_ADDTOCERTOCSP -- 20 (32)
3: 32:http://pki.omni.phish/oscp
CSURL_ADDTOCERTOCSP -- 20 (32)
4: 2:http://pki.omni.phish/CertEnroll/%3.crt
CSURL_ADDTOCERTCDP -- 2
CRLPublicationURLs
1st, you're publish to the local disk (C:\Windows\System32\CertSrv\CertEnroll\%3%8%9.crl) but nowhere else. Now you may have a manual process in place to upload this CRL to the CDP, in which case this is fine. Otherwise, you need to add another url (for example 65:file://\\[server]\[share]\%3%8%9.crl, where [server] is your CDP and [share] is a share for the directory containing your CRLs) so that new CRLs are automatically published to the CDP by the CA.
2nd, you are using a CDP of http://pki.omni.phish//CertEnroll/%3%4%9.crl. The %4 should be %8.
When you renew a CA certificate, you need the original CA certificate and CRL to still be available so that all end-entities that were previously issued certificates still work. Microsoft CAs do this by appending a (1) to the CRL name, just before the .crl extension for the 1st replacement certificate (Certificate #1 in the MMC) and (2) for the next renewal and so on. This is configured by the %8 in the CRLPublicationURLs registry key.
CAPublicationURLs
You are adding the URL to the CA certificate as http://pki.omni.phish/CertEnroll/%3.crt. You need to add a %4 after the %3.
The %4 does a similar job to what %8 does for CRLs. Without it, the CA certificate name remains the same.
There are three different ways you can fix these:
You can use the MMC - under Extensions on the CA Properties dialog. However, it's really clumsy to operate.
You can use the certutil -setreg command, but you have to overwrite all of the settings - you can't edit one line.
You can edit the registry directly at HKLM\SYSTEM\CurrentControlSet\Services\CertSrv\Configuration\[CA Name]
I find the latter is the simplest.
May I suggest some PKI and Microsoft ADCS revision before you touch production? :-)
This seems to be a popular question. I hope to differentiate my version from the others. Here's what I'm seeing when trying to connect to a Tomcat server, using the -debug option:
# openssl s_client -connect example.com:443 -debug
CONNECTED(00000003)
write to 0x694230 [0x694ef0] (187 bytes => 187 (0xBB))
[...]
read from 0x694230 [0x69a450] (7 bytes => 7 (0x7))
0000 - 15 03 03 00 02 02 28 ......(
15633:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:610:
The first thing to note is that the response does not include visible characters, so I'm unlikely to be connecting to a non-SSL-enabled port. I'm not certain which SSL library my version of openssl is using, but looking at https://boringssl.googlesource.com/boringssl/+/2214/ssl/s23_clnt.c is helpful, even with the wrong line numbers. p[1] is 0x03, which is SSL3_VERSION_MAJOR, and p[2] is 0x03, which is TLS1_2_VERSION_MINOR. p[0] is 0x15 (21 decimal), which is SSL3_RT_ALERT, which means that p[3] and p[4] should be 0 and 2 (the code doesn't use symbolic names for these), which they are. p[5] is also 0x02, which is SSL3_AL_FATAL, which doesn't look good. I'm guessing the server didn't like my initial write. However, that should give me a different error, so I'm wondering if openssl really doesn't recognize an otherwise valid protocol. Checking the version:
# openssl version
OpenSSL 0.9.8j-fips 07 Jan 2009
Yes, that looks a bit old. I guess I need to find a more recent version.
I configured WebSphere MQ v6.0.1.1 to be accessed by a Java client using JNDI and JMS via SSL. I tried the client and server on different machine, and on the same machine. I didn't get the same exception on the client side but it's related to a connection problem. On the server side I have nothing in the log.
Different machine client side error: Thread pool thread #0, Exception sending alert: java.net.SocketException: Software caused connection abort: socket write error
*** ServerHelloDone
*** Certificate chain
***
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1
Thread pool thread #0, WRITE: TLSv1 Handshake, length = 141
SESSION KEYGEN:
PreMaster Secret:
0000: 03 01 DB 7F 1B 78 46 24 D1 B3 7F 8F E4 2B 2D 35 .....xF$.....+-5
0010: 1B EB FF C9 01 C9 EC 12 07 0F F9 88 A9 12 45 77 ..............Ew
0020: 22 AE 79 17 C2 9D 4C 97 04 3E BA 91 1F 14 68 44 ".y...L..>....hD
CONNECTION KEYGEN:
Client Nonce:
0000: 50 76 7B FB 0D 45 F0 8D EF 54 E0 AB 2C 3A D4 7D Pv...E...T..,:..
0010: 24 52 FB FB 4F F4 1D E4 CC 2C 4E BA 8B CA 3E 54 $R..O....,N...>T
Server Nonce:
0000: 00 00 00 00 8F 53 C4 4D 2F 2F 41 AA EB 0A 80 2D .....S.M//A....-
0010: D0 E4 51 2A CC BC EE 94 92 BD CD E0 9B C9 EB 3D ..Q*...........=
Master Secret:
0000: 9D 93 ED F3 8A 97 39 7F 71 5F 34 52 30 A6 8E 38 ......9.q_4R0..8
0010: BC 17 59 28 78 63 AA 66 63 D0 EE 1C C6 54 CA D1 ..Y(xc.fc....T..
0020: F2 F0 ED 7E D7 81 33 C6 E3 1B 7C 46 C0 FB C8 5C ......3....F...\
Client MAC write Secret:
0000: 57 56 3D 05 B1 27 BE 56 A8 FD 07 64 0A 96 62 F2 WV=..'.V...d..b.
0010: AE AF B5 98 ....
Server MAC write Secret:
0000: F5 C7 B2 D2 79 11 90 6C C8 FD 86 8B E5 AE 59 71 ....y..l......Yq
0010: B2 A7 AB D3 ....
Client write key:
0000: 54 FD FD 8B C2 B4 8B 3F 38 23 25 5A 8A 41 26 9B T......?8#%Z.A&.
Server write key:
0000: 6D 9C C0 97 ED 21 3F 0E 0A FB E2 2B EE C0 5F 01 m....!?....+.._.
... no IV used for this cipher
Thread pool thread #0, WRITE: TLSv1 Change Cipher Spec, length = 1
*** Finished
verify_data: { 182, 85, 56, 238, 250, 233, 155, 119, 224, 254, 23, 196 }
***
Thread pool thread #0, WRITE: TLSv1 Handshake, length = 36
Thread pool thread #0, READ: TLSv1 Change Cipher Spec, length = 1
Thread pool thread #0, READ: TLSv1 Handshake, length = 36
*** Finished
verify_data: { 215, 140, 30, 150, 82, 161, 85, 160, 127, 189, 226, 74 }
***
%% Cached client session: [Session-1, SSL_RSA_WITH_RC4_128_SHA]
Thread pool thread #0, setSoTimeout(120000) called
Thread pool thread #0, WRITE: TLSv1 Application Data, length = 150
Thread pool thread #0, READ: TLSv1 Application Data, length = 56
Thread pool thread #0, WRITE: TLSv1 Application Data, length = 48
Thread pool thread #0, called close()
Thread pool thread #0, called closeInternal(true)
Thread pool thread #0, SEND TLSv1 ALERT: warning, description = close_notify
Thread pool thread #0, WRITE: TLSv1 Alert, length = 22
Thread pool thread #0, Exception sending alert: java.net.SocketException: Software caused connection abort: socket write error
Same machine client side error: Thread pool thread #0, Exception sending alert: java.net.SocketException: Broken pipe
It seems that the client writes whereas the server has already closed the connection.
EDIT:
10/10/12 2:26:23 PM - Process(10995.12) User(mqm) Program(amqrmppa)
AMQ9631: The CipherSpec negotiated during the SSL handshake does not match the
required CipherSpec for channel 'SSL.CHANNEL'.
EXPLANATION:
There is a mismatch between the CipherSpecs on the local and remote ends of
channel 'SSL.CHANNEL'. The channel will not run until this mismatch is
resolved. The CipherSpec required in the local channel definition is
'RC4_SHA_US'. The name of the CipherSpec negotiated during the SSL handshake is
'RC4_SHA_US'. A code is displayed if the name of the negotiated CipherSpec
cannot be determined.
ACTION:
Change the channel definitions for 'SSL.CHANNEL' so the two ends have matching
CipherSpecs and restart the channel. If the certificate in use by one end of
the channel is a Global Server Certificate, then the negotiated CipherSpec may
not match that specified on either end of the channel. This is because the SSL
protocol allows a Global Server Certificate to automatically negotiate a higher
level of encryption. In these cases specify a CipherSpec which meets the
requirements of the Global Server Certificate.
----- amqccisa.c : 851 --------------------------------------------------------
10/10/12 2:26:23 PM - Process(10995.12) User(mqm) Program(amqrmppa)
AMQ9999: Channel program ended abnormally.
EXPLANATION:
Channel program 'SSL.CHANNEL' ended abnormally.
ACTION:
Look at previous error messages for channel program 'SSL.CHANNEL' in the error
files to determine the cause of the failure.
----- amqrmrsa.c : 468 --------------------------------------------------------
Edit 2:
1 : DIS CHANNEL(SSL.CHANNEL) SSLCIPH
AMQ8414: Display Channel details.
CHANNEL(SSL.CHANNEL) CHLTYPE(SVRCONN)
SSLCIPH(RC4_SHA_US)
The Cipher used client side using JMSAdmin:
DEFINE QCF(QCF_NAME) SYNCPOINTALLGETS(YES) HOSTNAME(HOST) PORT(1414) TRANSPORT(client) QMANAGER(MYQMGR) CHANNEL(SSL.CHANNEL) SSLCIPHERSUITE(SSL_RSA_WITH_RC4_128_SHA)
Base on SSL CipherSpecs and CipherSuites RC4_SHA_US seems to match SSL_RSA_WITH_RC4_128_SHA.
There is a possibility when running the client on the same host as the QMgr to connect using bindings mode (shared memory) rather than over the network stack. Since bindings mode connections do not use the network stack, SSL would make no difference.
Assuming that the client is connecting over the network in both cases, there's nothing about the location of the client on one server or another that would influence the SSL connection other than that the client configurations were different from one instance to the other. The client is still going through the network stack and presenting a connection request to the QMgr's listener. The client finds its keystore the same way and all the QMgr sees is a connection request presented to the listener. So if you are getting different results between the two client instances, look for configuration discrepancies.
My method for debugging SSL connections on WMQ is to progress through the following sequence making sure each step works before advancing to the next:
Get the channel running without SSL. This validates that the channel names are spelled correctly, that a network route exists between the endpoints, that the QMgr's listener is running and that the client points to the right port.
Get the channel running with the SVRCONN definition set to SSLCAUTH(OPTIONAL). This performs an anonymous SSL connection similar to what your browser does. The QMgr presents a certificate to the client but does not request one back. This validates that the QMgr can find its certificate and that the client can find its trust store and properly validates the QMgr's cert.
Set the SVRCONN channel to SSLCAUTH(REQUIRED). This now requires the client to find its keystore (in the last step it required only its trust store) and to be able to find its certificate. It also requires the QMgr to be able to validate the client's cert.
The difference between the last two steps helps to isolate the problem by testing the SSL credential exchange in only one direction at a time.
You mention that there's "nothing in the log" when this happens. Which log? There are two sets of error logs. One is the server-global log at {WMQ home}/errors and the other is the QMgr error log at {WMQ home}/QMgrs/{QMgr name}/errors. Error log entries are made to the QMgr's error log when the MQ can identify the QMgr associated with the error. However, when an SSL connection is requested, MQ does not know which QMgr the connection has requested until after the SSL connection has completed. Because of this, many SSL negotiation errors on the server side are reported in the global error log.
I'd suggest running through the steps outlined above to determine which SSL credential exchange is failing and then looking for the error log entries in both the QMgr and global error log files. If this does not resolve the problem, please update your question noting the step in the process that fails and any error log entries identified by which log they were found in.
Also, V6 of MQ went out of service as of last month. Moving to a supported version of WMQ client and server would allow you to open a PMR, would provide much better Java/JMS performance, and will allow you to use more secure ciphers such as SHA-2 hashes and the new elliptic curve crypto supported by GSKit 8. Since WMQ V6 is out of support, at most only one additional Fix Pack will be released, after which security vulnerabilities in that version will not be addressed. If you are using SSL, I assume security is somewhat important and that you would want to use a version that will receive fixes if a new vulnerability is discovered.
UPDATE
Responding to the question update regarding the Global Server Certificate, it is necessary to understand how WMQ implements SSL/TLS. When the connection is made, the TLS negotiation (if you specify an SSL , WMQ performs a TLS session using an SSL cipher) follows the spec and the spec allows for a negotiation of the ciphersuite. When a global server certificate is used, the cert can specify a minimum acceptable cipher strength and this influences the negotiation.
When the TLS session is completed successfully, the connection is then handed to WebSphere MQ. Only then does the QMgr check the channel parameters such as "what QMgr is the connection requested for?" or, more importantly, "does the connection's negotiated cipherspec match the channel definition?" Typically it fails based on a mismatch between client and server. With a global server certificate it can fail because of a mismatch between the negotiated cipherspec versus the minimum acceptable as specified by the certificate.
What the error message is saying is that it is possible for the ciphersuite specified by the client to exactly match the cipherspec specified in the channel and still fail to connect because the global server certificate specifies a minimum cipher strength that is greater than that used by the client and the QMgr. There is more on this at Cipherspec mismatches in the Infocenter but in this case the error message is almost as informative as the Infocenter.