Hi
We’re having issues calling the API and it turns out there is an expired SSL certificate in the chain. Are you aware?
I’ve run the following:
openssl s_client -showcerts -connect api.companieshouse.gov.uk:443 | grep Verify
Which shows that the SSL certificate expired on 17th April 2021 at midday.
Kind regards
Sara
We have seen the same issue too with the following error in our app logs since the 17th.
26 Apr 10:38:36:222 [WebContainer : 9] ERROR com.xxxxxx.ic.implementation.CompaniesHouseApi - The connection with Companies house api could not be established: org.springframework.web.client.ResourceAccessException: I/O error on GET request for “https://api.companieshouse.gov.uk/company/XXXXXX/persons-with-significant-control”: com.ibm.jsse2.util.h: PKIX path validation failed: java.security.cert.CertPathValidatorException: The certificate expired at Sat Apr 17 12:00:00 UTC 2021; internal cause is:
java.security.cert.CertificateExpiredException: NotAfter: Sat Apr 17 12:00:00 UTC 2021; nested exception is javax.net.ssl.SSLHandshakeException
: com.ibm.jsse2.util.h: PKIX path validation failed: java.security.cert.CertPathValidatorException: The certificate expired at Sat Apr 17 12:00:00 UTC
2021; internal cause is:
java.security.cert.CertificateExpiredException: NotAfter: Sat Apr 17 12:00:00 UTC 2021 (IID=0004210019250777, TID=10002000006763249)
we are just not sure which certificate this refer’s to and the response running the command by Sara we see as
Verify return code: 0 (ok)
We have checked and cannot find any issues with our certificate for https://api.companieshouse.gov.uk
There are a couple of online tools you could use like
SSL Checker
Is it possible that your installation has an issue?
Hi Mark,
I do believe it is something in our application just not sure what at the moment, the first comment on this thread was interesting to us in that another party seemed to get the exact same issue with the same expiry date message we are currently seeing in our logs.
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
Sara
Hi,
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
Sara
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 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.
We have not seen any errors in relevant JVM logs regarding SSL handshaking error.