I guess you're referring to certificate validation for TLS.
Before getting to the answer, let's cover some background. In the lingo of TLS, there are two "peers" that communicate. In one-way TLS, one peer requests the other peer to authenticate. Typically the first peer is called the "client" and the second the "server". The response from the server for authentication includes the server certificate chain.
This Cloudflare blog explains and provides a diagram.
Also , this stackexchange answer provides a clear explanation for what the server sends back:
the server is supposed to send a complete, ordered chain of certificates, starting with the server's certificate proper, then a certificate for the intermediate CA that issued it, then a certificate for the intermediate CA that issued the previous intermediate CA certificate, and so on. At the end of the chain, the server has the option to include or not include the root CA certificate...
In the TLS model, the clients maintain or rely upon a TrustStore. This is a generic term; it applies to any TLS peer, and is not specific to Apigee. The truststore is a list of certificates of root CAs, that are explicitly trusted by the client. The list can be large or small, as appropriate.
Then, the client can evaluate whether to trust the server, by examining the certificate chain. Something like this:
- check the "top most" cert, find its signer
- get the next cert in the chain, determine if that matches the signer of the previous cert. If not, fail (chain of trust is broken).
- if it does match, then go back to step 2.
- when there are no more certs, you've reached the root in the chain.
At the bottom of the chain is the root CA's certificate. That must be present in the truststore.
An example: client Charlie starts a handshake with server Sally. Sally sends her certificate chain. It consists of
- a certificate for Sally, signed by Bob
- a certificate for Bob, signed by Alice
- a certificate for Alice, signed by Maxwell. Maxwell is a root CA.
Basically this is a chain that says... Bob vouches for Sally, Alice vouches for Bob, and Maxwell vouches for Alice. So if you trust Maxwell, you can trust that Sally is who she says she is. The client then checks - is Sally's certificate really signed by Bob? Is Bob's cert really signed by Alice? Is Alice's cert really signed by Maxwell? If all of those are true, then the client needs to ask "Do I trust Maxwell?" If Maxwell's certificate is in the client's truststore,, then the client trusts Maxwell, and can trust every party in the chain.
These chains can be pretty long, but typically consist 3 or 4 certificates. And there is a twist to what I wrote above - each cert has a validity period, a "not before" and a "not after" time. Validating a cert consists of checking "is the cert valid (not expired)?" and "do I trust the certificate?" The above chain-of-trust is only about the latter. Checking validity dates is really simple, but the peer needs to do it, obviously, for every cert in the chain. So replace "is Sally's certificate really signed by Bob?" with "is Sally's certificate really signed by Bob, and valid (*not expired)?" .
AFAIK, the most popular web browsers use the OS-specific or platform-specific certificate stores. So for example, Chrome on Windows will rely on the Windows-wide Trusted CA list. aka Truststore. Similarly, Chrome on MacOS will rely on the MacOS-managed list of trusted root CAs.
With Apigee, you have control over the Truststore. This means you can tell an Apigee proxy which root CAs it should trust. When connecting to a single endpoint, under control of a partner company, really you should need just a single certificate in your truststore. You do not need the entity certificate in the truststore, nor do you need intermediate certs to appear in the truststore. In fact you SHOULD NOT load those things into your truststore. Just the cert of any root CA you would like to trust.
ok now let's back up to your questions.
entity certificate is expired but intermediate and root certificates are having validity. Do I need to upload new certificate to truststore ?
If the Apigee connects to a server, and the server, as part of the TLS handshake, sends back a chain of certificates including a certificate that is expired (either the topmost cert or any cert in the chain), then Apigee should reject the connection / fail the handshake. To rectify the problem, get a new, refreshed certificate for the server, and configure the server to send THAT cert back in its handshake. There will be no change required to Apigee to handle this, assuming the rest of the chain of certificates is the same. After the server begins sending back a valid, non-expired certificate in its chain, Apigee will happy complete the TLS handshake.
Will Apigee truststore verifies all certificates (entity, intermediate and root) expiry date or only root certificate expiry date ?
The Apigee RUNTIME (not the truststore) will verify all certificates, including the validity dates on each one. The truststore is there to check the chain of trust, as I explained above. To get this, you need to set the Enforce element to true, in the SSLInfo. check the documentation, it states this explicitly. It says that when Enforce is set to true,
connections will fail for targets with invalid certs, expired certs, self-signed certs, certs with a hostname mismatch, and certs with an untrusted root.
...which maybe isn't quite as definitive as you might like. It doesn't explicitly say "Apigee checks the expiry of every certificate in the chain", but in actuality, Apigee checks the expiry of every certificate in the chain. This is just how TLS validation works.
LinkedIn
Twitter
