validating SSL certificate using java Apache http client

[jacob deiter]

I'm using java and Apache Http client to access a Public Rest API. I got the Rest API's URI by just google search. When I looks at the URL, it says https, and the SSL certificate is issued by "Amazon".

So my question is how to verify the certificate at java code, if possible could you please provide any sample code to validate the certificate?

[Matthew Bendford]

Let Java do it for you (yes, it's done explicitly the very long way):

import java.io.*;
import java.security.*;
import javax.net.ssl.*;
public final class TLSTest
{
	public final static void main(final String... args) throws Exception
	{
		SecureRandom secureRandom=SecureRandom.getInstance("SHA1PRNG");
		secureRandom.setSeed(SecureRandom.getInstanceStrong().generateSeed(32));
		SSLContext sslContext=SSLContext.getInstance("TLSv1.2");
		TrustManagerFactory trustManagerFactory=TrustManagerFactory.getInstance("PKIX");
		KeyStore trustStore=KeyStore.getInstance(new File(System.getProperty("java.home"), "lib/security/cacerts"), "changeit".toCharArray());
		trustManagerFactory.init(trustStore);
		sslContext.init(null, trustManagerFactory.getTrustManagers(), secureRandom);
		SSLSocket sslSocket=(SSLSocket)sslContext.getSocketFactory().createSocket("google.com", 443);
		sslSocket.startHandshake();
		sslSocket.close();
	}
}

run it with: java -Djava.security.debug=all TLSTest - and you may get this output (trucated as the log is about 100kb):

certpath: AnchorCertificate.contains: matched CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2
certpath: trustedMatch = true
certpath: --------------------------------------------------------------
certpath: Executing PKIX certification path validation algorithm.
certpath: Checking cert1 - Subject: CN=GTS CA 1O1, O=Google Trust Services, C=US
certpath: Set of critical extensions: {2.5.29.15, 2.5.29.19}
certpath: -Using checker1 ... [sun.security.provider.certpath.UntrustedChecker]
Provider: MessageDigest.SHA-256 algorithm from: SUN
certpath: -checker1 validation succeeded
certpath: -Using checker2 ... [sun.security.provider.certpath.AlgorithmChecker]
certpath: Constraints.permits(): SHA256withRSA Variant: tls server
certpath: KeySizeConstraints.permits(): RSA
certpath: -checker2 validation succeeded
certpath: -Using checker3 ... [sun.security.provider.certpath.KeyChecker]
certpath: KeyChecker.verifyCAKeyUsage() ---checking CA key usage...
certpath: KeyChecker.verifyCAKeyUsage() CA key usage verified.
certpath: -checker3 validation succeeded
certpath: -Using checker4 ... [sun.security.provider.certpath.ConstraintsChecker]
certpath: ---checking basic constraints...
certpath: i = 1, maxPathLength = 2
certpath: after processing, maxPathLength = 0
certpath: basic constraints verified.
certpath: ---checking name constraints...
certpath: prevNC = null, newNC = null
certpath: mergedNC = null
certpath: name constraints verified.
certpath: -checker4 validation succeeded
certpath: -Using checker5 ... [sun.security.provider.certpath.PolicyChecker]
certpath: PolicyChecker.checkPolicy() ---checking certificate policies...
certpath: PolicyChecker.checkPolicy() certIndex = 1
certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: explicitPolicy = 3
certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: policyMapping = 3
certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: inhibitAnyPolicy = 3
certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: policyTree = anyPolicy  ROOT

certpath: PolicyChecker.processPolicies() policiesCritical = false
certpath: PolicyChecker.processPolicies() rejectPolicyQualifiers = true
certpath: PolicyChecker.processPolicies() processing policy: 2.23.140.1.2.2
certpath: PolicyChecker.processParents(): matchAny = false
certpath: PolicyChecker.processParents(): matchAny = true
certpath: PolicyChecker.processParents() found parent:
anyPolicy  ROOT

certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: explicitPolicy = 2
certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: policyMapping = 2
certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: inhibitAnyPolicy = 2
certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: policyTree = anyPolicy  ROOT
  2.23.140.1.2.2  CRIT: false  EP: 2.23.140.1.2.2  (1)

certpath: PolicyChecker.checkPolicy() certificate policies verified
certpath: -checker5 validation succeeded
certpath: -Using checker6 ... [sun.security.provider.certpath.BasicChecker]
scl:  getPermissions ProtectionDomain  (jrt:/jdk.localedata <no signer certificates>)
 jdk.internal.loader.ClassLoaders$PlatformClassLoader@2e5d6d97
 <no principals>
 java.security.Permissions@5f3a4b84 (
 ("java.lang.RuntimePermission" "accessSystemModules")
)


scl: 
certpath: ---checking validity:Wed Apr 21 00:05:29 CEST 2021...
certpath: validity verified.
certpath: ---checking subject/issuer name chaining...
certpath: subject/issuer name chaining verified.
certpath: ---checking signature...
Provider: MessageDigest.SHA-256 algorithm from: SUN
Provider: Signature.SHA256withRSA verification algorithm from: SunRsaSign
certpath: signature verified.
certpath: BasicChecker.updateState issuer: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2; subject: CN=GTS CA 1O1, O=Google Trust Services, C=US; serial#: 149699596615803609916394524856
certpath: -checker6 validation succeeded
certpath: -Using checker7 ... [sun.security.provider.certpath.AlgorithmChecker]
certpath: Constraints.permits(): SHA256withRSA Variant: tls server
certpath: KeySizeConstraints.permits(): RSA
certpath: -checker7 validation succeeded
certpath: 
cert1 validation succeeded.

certpath: Checking cert2 - Subject: CN=\2A.google.com, O=Google LLC, L=Mountain View, ST=California, C=US
certpath: Set of critical extensions: {2.5.29.15, 2.5.29.19}
certpath: -Using checker1 ... [sun.security.provider.certpath.UntrustedChecker]
Provider: MessageDigest.SHA-256 algorithm from: SUN
certpath: -checker1 validation succeeded
certpath: -Using checker2 ... [sun.security.provider.certpath.AlgorithmChecker]
certpath: Constraints.permits(): SHA256withRSA Variant: tls server
certpath: KeySizeConstraints.permits(): RSA
certpath: -checker2 validation succeeded
certpath: -Using checker3 ... [sun.security.provider.certpath.KeyChecker]
certpath: -checker3 validation succeeded
certpath: -Using checker4 ... [sun.security.provider.certpath.ConstraintsChecker]
certpath: ---checking basic constraints...
certpath: i = 2, maxPathLength = 0
certpath: after processing, maxPathLength = 0
certpath: basic constraints verified.
certpath: ---checking name constraints...
certpath: prevNC = null, newNC = null
certpath: mergedNC = null
certpath: name constraints verified.
certpath: -checker4 validation succeeded
certpath: -Using checker5 ... [sun.security.provider.certpath.PolicyChecker]
certpath: PolicyChecker.checkPolicy() ---checking certificate policies...
certpath: PolicyChecker.checkPolicy() certIndex = 2
certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: explicitPolicy = 2
certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: policyMapping = 2
certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: inhibitAnyPolicy = 2
certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: policyTree = anyPolicy  ROOT
  2.23.140.1.2.2  CRIT: false  EP: 2.23.140.1.2.2  (1)

certpath: PolicyChecker.processPolicies() policiesCritical = false
certpath: PolicyChecker.processPolicies() rejectPolicyQualifiers = true
certpath: PolicyChecker.processPolicies() processing policy: 2.23.140.1.2.2
certpath: PolicyChecker.processParents(): matchAny = false
certpath: PolicyChecker.processParents() found parent:
  2.23.140.1.2.2  CRIT: false  EP: 2.23.140.1.2.2  (1)

certpath: PolicyChecker.processPolicies() processing policy: 1.3.6.1.4.1.11129.2.5.3
certpath: PolicyChecker.processParents(): matchAny = false
certpath: PolicyChecker.processParents(): matchAny = true
certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: explicitPolicy = 2
certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: policyMapping = 2
certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: inhibitAnyPolicy = 2
certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: policyTree = anyPolicy  ROOT
  2.23.140.1.2.2  CRIT: false  EP: 2.23.140.1.2.2  (1)
    2.23.140.1.2.2  CRIT: false  EP: 2.23.140.1.2.2  (2)

certpath: PolicyChecker.checkPolicy() certificate policies verified
certpath: -checker5 validation succeeded
certpath: -Using checker6 ... [sun.security.provider.certpath.BasicChecker]
certpath: ---checking validity:Wed Apr 21 00:05:29 CEST 2021...
certpath: validity verified.
certpath: ---checking subject/issuer name chaining...
certpath: subject/issuer name chaining verified.
certpath: ---checking signature...
Provider: MessageDigest.SHA-256 algorithm from: SUN
Provider: Signature.SHA256withRSA verification algorithm from: SunRsaSign
certpath: signature verified.
certpath: BasicChecker.updateState issuer: CN=GTS CA 1O1, O=Google Trust Services, C=US; subject: CN=\2A.google.com, O=Google LLC, L=Mountain View, ST=California, C=US; serial#: 207119307109833455258802865152455333642
certpath: -checker6 validation succeeded
certpath: -Using checker7 ... [sun.security.provider.certpath.AlgorithmChecker]
certpath: Constraints.permits(): SHA256withRSA Variant: tls server
certpath: KeySizeConstraints.permits(): EC
certpath: KeySizeConstraints.permits(): EC
certpath: KeySizeConstraints.permits(): EC
certpath: KeySizeConstraints.permits(): RSA
certpath: -checker7 validation succeeded
certpath: 
cert2 validation succeeded.

certpath: Cert path validation succeeded. (PKIX validation algorithm)
certpath: --------------------------------------------------------------
Provider: MessageDigest.SHA-256 algorithm from: SUN
Provider: Signature.SHA256withECDSA verification algorithm from: SunEC
drbg [HashDrbg@1414147750]: configure Hash_DRBG,null,0,reseed_only with Hash_DRBG,null,true,-1,none,null
drbg [HashDrbg@1414147750]: configured Hash_DRBG,SHA-256,128,reseed_only
Provider: SecureRandom.DRBG algorithm from: SUN
Provider: KeyPairGenerator.XDH algorithm from: SunEC
Provider: KeyAgreement.XDH algorithm from: SunEC
Provider: KeyGenerator.SunTlsExtendedMasterSecret algorithm from: SunJCE
Provider: MessageDigest.SHA-256 algorithm from: SUN
Provider: KeyGenerator.SunTls12KeyMaterial algorithm from: SunJCE
Provider: MessageDigest.SHA-256 algorithm from: SUN
Provider: KeyGenerator.SunTls12Prf algorithm from: SunJCE
Provider: MessageDigest.SHA-256 algorithm from: SUN
Provider: Cipher.AES/GCM/NoPadding, mode: encryption, algorithm from: SunJCE
Provider: Cipher.AES/GCM/NoPadding, mode: decryption, algorithm from: SunJCE
Provider: KeyGenerator.SunTls12Prf algorithm from: SunJCE
Provider: MessageDigest.SHA-256 algorithm from: SUN
Provider: Cipher.AES/GCM/NoPadding, mode: encryption, algorithm from: SunJCE

[jacob deiter]

Thank you Benford for your reply!

I am using Apache Http client tool to access the Rest API.  How it can be done in Http client?

P.S: I am not sure how genuine the Rest API is, if the API is not secure enough then I do not want to call it from Http client tool.

[Rob Spoor]

If the root certificate is issued by Amazon, you probably don't have to do anything. Java comes with a set of pre-defined trusted root certificates.

If you need to use custom certificates, you need to create a connection manager using something like this:

SSLConnectionSocketFactory sslSocketFactory = new SSLConnectionSocketFactory(sslContext);

Registry<ConnectionSocketFactory> registry = RegistryBuilder.<ConnectionSocketFactory>create()
        .register("http", PlainConnectionSocketFactory.getSocketFactory())
        .register("https", sslSocketFactory)
        .build();

PoolingHttpClientConnectionManager connectionManager = new PoolingHttpClientConnectionManager(registry);

The SSLContext can be built using SSLContextBuilder, it has methods to create an SSLContext that uses specific trust key stores.


@Matthew: you don't need to explicitly load the cacerts truststore, that's done by default.

[Tim Holloway]

jacob deiter wrote:P.S: I am not sure how genuine the Rest API is, if the API is not secure enough then I do not want to call it from Http client tool.

That depends on what part of the system you're talking about. You can have sloppy code on client and/or server, but HTTPS provides a secure channel between the two.

If you make a plain-text HTTP request to a server port that's configured for HTTPS, you will get an error because HTTP does not include encryption negotiation (or encryption, period). Conversely, HTTPS sent to an HTTP port will be seen as garbage by the server.

Normally, it's enough to request a URL with the protocol value "https" to ensure that TLS/SSL will be automatically selected by the client. And of course, if you don't explicitly specify, the request will target the server's port 443.

So you can be assured that SOME encryption will be used. The more serious concern is that the encryption algorithm used isn't one that has been "broken". That's primarily up to the JVM plus whatever plug-in algorithms you might manually introduce, and it's why having a recent JVM is preferable (keeping an eye on security bulletins). If you run into issues where you need to manually control which algorithms in the available set are / are not to be used, well I'll hand you back to Rob.

[Matthew Bendford]

jacob deiter wrote:How it can be done in Http client?

Pretty much the same way you do most crypto things in Java: Just use what ever client-code you have with some TLS secured endpoint. As you said you use some URL starting with "https://" it doesn't matter what you use as your client code:
(new URL("https://")).openConnection() works as well as going full blown like I did using raw sockets or some other lib like Apache Commons.
Unless some lib would re-implement TLS on its own - and I'm only aware of very few that actually do - it just has to rely on the crypto stuff SE-api comes with in its base package.
So, no matter what you use - it all ends up in a call to SSLSocket.startHandshake() either explicitly or implicitly - and if it's the first connection any call to getDefault() will result in some defaults set up in pretty much the way I posted - as that's the few lines buried very deep in the classes responsible for all the crypto stuff that Java can do all on its own without any additional lib.

Rob Spoor wrote:If the root certificate is issued by Amazon, you probably don't have to do anything. Java comes with a set of pre-defined trusted root certificates.

Be aware: On many Linux distributions Java uses a symlink to point at the CA-store often provided by packages like mozilla-ca. So it actually relies on the system wide installed CA certs rather than comming with its own set.
Windows binaries are often supplied with a good common set of certificates - round about 90 or so.

Rob Spoor wrote:@Matthew: you don't need to explicitly load the cacerts truststore, that's done by default.

I'm aware of that - in fact the lines I posted are what happen anyway the first time any getDefault() method is called: It ends up in SSLContext.init(null, null, null) which then in turn sets up some SecureRandom and loads the default cacerts file.
I did it on purpose cause OP seems a bit too much focused on using apache commons - although even that lib still relies on whatever the VM its run on comes with - as apache doesn't re-implement a full TLS stack on its own - at least not that I'm aware of it.

Tim Holloway wrote:The more serious concern is that the encryption algorithm used isn't one that has been "broken". That's primarily up to the JVM plus whatever plug-in algorithms you might manually introduce, and it's why having a recent JVM is preferable (keeping an eye on security bulletins). If you run into issues where you need to manually control which algorithms in the available set are / are not to be used, well I'll hand you back to Rob.

I'm not aware of any recent important security patches to the JSSE and JCE stuff - but in fact even with the newest Java16 you still can set up and use SSLv2 without getting any warnings. It's up to some own logic to check what SSL/TLS versions and ciphersuites are enabled for handshake - and what the connection ends up with.

[Tim Holloway]

Java SE 14 for Linux keeps certs in a binary file in JAVA_HOME/lib/security - which also has a cert blacklist file which is in text form. The cacerts file may be a keystore, but keystores don't appear to have a "magic number" that identifies them as such and I wasn't willing to do further research. The builtin cacert file probably does have an anti-tampering signature, since that's good practice.

However, that cannot be considered as the definitive cert set since you can import your own certs, Again, I'm too lazy to research the cert-finder mechanism for Java. I'm sure if they wanted to, they could tap other OS and web client sysfems as well, if desired.

More to the point, as Rob has said, even the third-party libraries tend to be built on the JVM's internal HTTP protocol services, which are vetted by security professionals. You COULD build your own transport and SSL up from raw sockets, but what would be the benefit?

[Tim Holloway]

Update: Yes, the cacerts file in my JVM is a keystore. It has 93-factory-supplied entries, including 4 top-level Amazon certs, plus certs for verisign, thawte, godaddy and letsencrypt. Neither Oracle nor Sun apparently went into the cert business, however.