Would it be possible for you to confirm what changed during your maintenance window at around 12pm on the 17th? (https://www.informdirect.co.uk/news/companies-house-maintenance-periods/ )
Just wondering if your certificates were changed (old ones removed maybe?) to block older encryption standards to force stronger TLS1.2 connections/security?
Cheers
Hi Mark
Our installation has been in place for a few years now and nothing has changed at our end, so it’s unlikely that there is a problem with our setup.
There are 2 SSL cert routes, SNI and non-SNI. The SNI one is working fine and I assume this is the one that the likes of SSL Checker is using. However, we have to use the non-SNI one, which has an expired cert in the chain.
Have you tried running openssl s_client -showcerts -connect api.companieshouse.gov.uk:443 | grep Verify? This looks at the non-SNI route and may indicate the issue.
Kind regards
That appears to be our same findings & cause. (The openssl command shows it working but that is due to newer openssl libraries I believe and the same reason testing via curl shows everything is ok, our application unfortunately is stuck on a far older Java version which doesn’t support SNI so looking into alternatives to get us back online if the cert cannot be fixed on the companies house side)
Can someone at companies house confirm the findings for the non-SNI certificate? Is this something you can fix or is this no longer being offered?
Thanks
@MArkWilliams had to add my response here due to a limit of 3 replies per thread !?
We have just checked and we can see our calls are all successful now.
As for using IP addresses we are using the api.companieshouse.gov.uk domain in our requests but I will check if there is something strange somewhere converting that to an IP address.
Thanks for your help getting this resolved.
We have just found your issue.
We had an expired certificate as the catch-all if your address did not match api.companieshouse.gov.uk or api.company-information.service.gov.uk
So I suspect that you may be using IP addresses to access our API.
We have just made the default catch-all certificate the same as the main multi-domain certificate, so hopefully that has fixed your specific issue.
Please let us know.
Hi Mark
This is working for us too now. We’re not using the IP address either and shouldn’t be converted to the IP address along the way.
But all sorted now.
Kind regards
Hello All,
This issue started again.
We have start getting same issue again from 24th of May 2022.
Is there any certificate updates?
Hi Team,
This is reply from Middleware side we have received request from Application Team stating that needs to enable TLS1.2 along with strong ciphers from the Websphere Application Server side, earlier it was TLS protocol.
As the destination api updated to TLS1.2 due to this communication was not happening from source to destination api.
Steps followed for enabling TLS1.2 and post we have added below Ciphers.
SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256
SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Implemented on both App server and adminagent instances.
Add the following three parameters to force TLSv1.2 in Generic JVM Arguments
a. Go to Servers > Server Types > WebSphere Application servers > {{ Server Name }} > Under Server Infrastructure > + Java and Process Management > Process definition > Java Virtual Machine
b. In field Generic JVM arguments:
Add the following three arguments :
-Dcom.ibm.jsse2.overrideDefaultProtocol=TLSv1.2 -Dhttps.protocols=TLSv1.2 -Djdk.tls.client.protocols=TLSv1.2
2. Add the following parameter to enable the Cipher Suites to use
a. Servers > Server Types > WebSphere Application servers > {{ Server Name }} > Under Server Infrastructure > + Java and Process Management > Process definition > Java Virtual Machine > Custom properties
b. Click New
Name: https.cipherSuites
Value: SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256,SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384,SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256,SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA,SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384,SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_AES_128_GCM_SHA256,SSL_RSA_WITH_AES_256_GCM_SHA384,SSL_RSA_WITH_AES_128_CBC_SHA256,SSL_RSA_WITH_AES_256_CBC_SHA256,SSL_RSA_WITH_AES_128_CBC_SHA,SSL_RSA_WITH_AES_256_CBC_SHA
3. Enable the EC Ciphers (Elliptical-circular)
a. Security > Global security > Custom properties
b. Click New
Name: com.ibm.websphere.ssl.include.ECCiphers
Value: true
4.Enable Cipher Suites
a) Security > SSL certificate and key management > SSL configurations > NodeDefaultSSLSettings > Quality of protection
(QoP) settings
b) Then make the following changes :
(i)Client authentication = Supported
(ii)Protocol = TLSv1.2
(iii)Cipher suite groups = Custom
(iv)Click Update selected ciphers
c) Select ciphers to add = Add these ciphers (SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256 SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
Post the Implementation we have applied the required javaSDK patch at Websphere end.
Please find the Java & SDK version Output.
/opt/WebSphere7/java/jre/bin> ./java -version
java version “1.6.0”
Java™ SE Runtime Environment (build pxi3260sr16fp60-20180213_02(SR16 FP60))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260sr16fp60-20180125_377078 (JIT enabled, AOT enabled)
J9VM - 20180125_377078
JIT - r9_20180125_377078
GC - GA24_Java6_SR16_20180125_1132_B377078)
JCL - 20180209_01
Request you to validate the above steps and do let us know any changes need to be done from our end.
Note:
We have not seen any errors in relevant JVM logs regarding SSL handshaking error.