Reading expiration dates on pem or pfx certificates

Hello.if you have a minute, I was thinking of coding an "early wanring"/detection to send an email when a tls/ssl cert is within, say, 60 days of expiration, then 30, etc. However,java.security.KeyStore doesn't seem to like a pem format converted from pfx with openssl. Here is the sequence of events..

1.  issued a self-signed my_cert.pfx for server by CA

2.  command line....  openssl pkcs12 -in my_cert.pfx -out my_cert.pem -nodes

3. Deployed/configured my_cert.pem

4. Been monitoring the expiration dates via command line openssl but thought I'd try to create that early warning utility

5. These are the key lines in code (standard fare I think out of what I see)...

KeyStore keystore=KeyStore.getinstance(KeyStore.getDefaultType()); keystore.load(new FileInpitStream(file_path),"password".toCharArray());

6. Hard coding my_cert.pfx for file_path, the pfx seems to load and the expiration date is read correctly (later in code).

7. However, my_cert.pem for file+path throws the java.io.IOException Invalid keystore format exception on the load line. ugh. I'm not sure what's up, the pem has been validated and as I said, been doing it's TLS job. Thank you so much for reading.

If you are starting with a PEM (Base64 encoded) representation of the certificate, remove the armoring, use  the CertificateFactory to create a certificate, and then read whatever attributes you need.

Here's a quick example:import java.io.ByteArrayInputStream; import java.io.IOException; import java.nio.file.Files; import java.nio.file.Paths; import java.security.cert.CertificateException; import java.security.cert.CertificateFactory; import java.security.cert.X509Certificate; import java.util.Base64; import java.util.Date; import org.junit.jupiter.api.Test; public class X509Test {    @Test    void pemCertExpiry() throws IOException, CertificateException {        final String pemFilePathStr = "/tmp/SGP.26_v1.3_files/Valid Test Cases/CertificateIssuer/CERT_CI_ECDSA_NIST.pem";        var expiryDate = getCertificateExpiryDateFromPem(pemFilePathStr);        System.out.println(expiryDate);    }    Date getCertificateExpiryDateFromPem(String pemFilePathStr) throws IOException, CertificateException {        var pemStr = Files.readString(Paths.get(pemFilePathStr));        var encoded = fromPem(pemStr);        try (var is = new ByteArrayInputStream(encoded)) {            var cert = (X509Certificate) CertificateFactory.getInstance("X.509").generateCertificate(is);            return cert.getNotAfter();        }    }    byte[] fromPem(String pem) {        var str = pem                .replace("-----BEGIN CERTIFICATE-----", "")                .replaceAll(System.lineSeparator(), "")                .replace("-----END CERTIFICATE-----", "");        return Base64.getDecoder().decode(str);    } }mvn -q verify -Dtest=X509Test Thu Apr 01 01:27:51 PDT 2055

If starting with a DER:
   @Test    void derCertExpiry() throws IOException, CertificateException {        final String derFilePathStr = "/tmp/SGP.26_v1.3_files/Valid Test Cases/CertificateIssuer/CERT_CI_ECDSA_NIST.der";        var expiryDate = getCertificateExpiryDateFromDer(derFilePathStr);        System.out.println(expiryDate);    }    Date getCertificateExpiryDateFromDer(String defFilePathStr) throws IOException, CertificateException {        var is = Files.newInputStream(Paths.get(defFilePathStr));        var cert = (X509Certificate) CertificateFactory.getInstance("X.509").generateCertificate(is);        return cert.getNotAfter();    }

ok...let me look at that... thanks.

I see the problem with my
KeyStore keystore=KeyStore.getinstance(KeyStore.getDefaultType());
line where the default is apparently PKSCS12. If I use this line...

KeyStore keystore=KeyStore.getinstance("PKCS12");

it still works for PFX. But I wouldn't know the instance type for a PEM file (out of the list of allowable KeyStore instance types I see)...

jceks
jks
dks
pkcs11
pkcs12

so I'll look at the example you provided as maybe it has to do with the armoring.

With a PKCS12 archive, it should be something like this (untested; assuming only a single entry):    Date getCertificateExpiryDateFromPcks12(String p12FilePathStr, char[] passphrase)            throws IOException, KeyStoreException, NoSuchAlgorithmException, CertificateException {        var is = Files.newInputStream(Paths.get(p12FilePathStr));        var keystore = KeyStore.getInstance("PKCS12");        keystore.load(is, passphrase);        var aliases = keystore.aliases();        if (aliases.hasMoreElements()) {            var cert = (X509Certificate) keystore.getCertificate(aliases.nextElement());            return cert.getNotAfter();        }        return null;    }

thanks so much. i was able to write a java program for the pkcs12 but i have a question regarding the pem code, actually all three types you posted. Isn't the var declaration javascript?

Thomas Griffith wrote:Isn't the var declaration javascript?

The reserved type name var was added in Java 10.  Instead of explicitly stating the type, it can inferred based on the right-hand-side of the declaration statement (the initializer).

The details are here: JEP 286: Local-Variable Type Inference

oh, ok. I'm kinda stuck with 8 for now but I'll work with it. I was wondering about security of a pem file, or a ley file in pem format, sitting on a server like Tomcat. What would keep anybody from coding an inputstream, bytearray reader to  read a private key? Password protection on the file? Is the password applied in openssl when converting from pfx to pem?

When the key is stored in PEM or DER format, the only protection is going to be whatever access control is provided by the operating system and file system.

I believe that Tomcat does support using storing the private key (and certificate) in a KeyStore, which would normally be password protected.

yeah, I was going to look at adding a password to the pem file when I converted it from the CA issued pfx. I had to do that because the certificates are out of order in the pfx, had to reorder them into server, intermediate, root.  The original pfx has a passcode which i had to enter in openssl when converting to pem. I presumed this would carry over to the resultant pem but I guess it doesn't...so I was going to look into adding a password to the pem during the conversion step in openssl. But i'm not entirily sure if that password would protect form somebody streaming the pem for the private key, like I'm attempting here for the expiration date.

I'm working in 8 and I'm having some trouble with the following lines (haivng to explicitly declare the objects)...

PemFilePathString="c:\blah\blah\my.pem" String pemStr=Files.readString(Paths.get(PemFilePathString)); byte[] encoded.fromPem(pemStr);

I am getting compile error "incompatible types: String cannot be converted to URI"

so figuring this is looking for a url and not a path, changed to...

String content = new String(Files.readAllBytes(Paths.get(fileName)));

Same error "incompatible types: String cannot be converted to URI"

Should I do this with a FileInputStream? ty.

If you are going to use the Windows path notation, you will need to escape the bash slashes: String pemFilePathString="c:\\blah\\blah\\my.pem";
I prefer to use Unix paths even when running in a Windows environment: String pemFilePathString="c:/blah/blah/my.pem";

yeah, i escape them already, I was typing what the path format looks like from System.out.println....

Thomas Griffith wrote:... the certificates are out of order in the pfx, had to reorder them into server, intermediate, root.

If there is more than one entry in the archive, then you may need to iterate through then to find the host certificate.  I didn't do that in the example that I shared (I mentioned: assuming only a single entry),

If you can share a more complete example of the non-working code, I (or someone else) can take a look.

Hi. I wound up converting the pem to a password protected key store, as you suggested, after realizing pem basically exposes the private key and certs. I converted the pem back to pkcs12 with openssl and set up the config in server.xml. Then coded a scheduled process using the core PKCS12 code above to read the expiration date stuff and starting the reminders on a weekly basis once it gets to 90 days before expiration. thanks so much.

With the password protected key store, however, brings the Tomcat issue of storing passwords in plain text within server.xml  (for the key store) and any context.xml files (for JDBC and other db system connects). Do you know if that Digester.bat can be used to SHA-256 passwords, then the hash can be thrown into the above xml files in lieu of clear text passwords, and if Tomcat stores these SHA-256 mappings with clear text passwords somewhere as needed for the external db connects  (as well as the connect to the PKCS12 keystore for the expiration date)?

Thomas Griffith wrote:... Then coded a scheduled process using the core PKCS12 code above to read the expiration date stuff and starting the reminders on a weekly basis once it gets to 90 days before expiration. thanks so much.

You're welcome - glad to hear that you got it working.

Thomas Griffith wrote:... after realizing pem basically exposes the private key and certs

There is nothing sensitive in the X.509 certificates.  In-fact they are offered to the (anonymous) client in plain-text every time a TLS connection is being established.

Thomas Griffith wrote:With the password protected key store, however, brings the Tomcat issue of storing passwords in plain text within server.xml  (for the key store)

I'm pretty sure that Tomcat supports PKCS12 keystores directly, so you should not need to keep the private key in the clear on the file system (however, the encryption key for the keystore will be in the file system).

Thomas Griffith wrote:Do you know if that Digester.bat can be used to SHA-256 passwords

I don't know what Digester.bat is, but I can't imagine it working.  The private key is used to create and verify digital signatures - it is not a password.

I'm not sure what your security concerns/requirements are, but I worked on some PCI (payment card industry) like projects where we were absolutely paranoid about the private key get exfiltrated, and would not have passed security audits having the private key or encrypting key in the open.  Our solution was to use HSMs to generate and store the private keys (and symmetric encryption keys), and have the HSM sign and verify content using these internally-stored keys.  Keys stored in an HSM cannot be extracted.  The cost of an HSM can range from $100 for a low-end USB device to $50,000 for a high-end network-connected device.

oh, thanks for bringing HSM up. I was curious, so the HSM is connected at all times to the server/vm where Tomcat or any HTTP server using TLS/SSL would be running, is that right? Becasue every HTTPS connection requires the private key for decryption, right? the HSM is essentially a server partition?

Regarding Tomcat passwords, in server.xml,  it requires the

certificateKeyStoreFile (path within Tomcat Home)
certificateKeystorePassword
certificateKesystoreType (JKS, PKCS12, etc)

But I was hoping to hash the key store password part here in server.xml as well as in context xml files with JDBC connections (containing passwords to dbs). Was kind of reading that Tomcat relies on OS security for this but hoping to hash them wiht digester.bat, put the hash into these xml configs, and Tomcat able to take hash and feed the real plain text passwords to the keystore or dbs. That's why i am looking at the digesster.bat thing.

How would Tomcat be able to retrieve the original password from a password hash? Hash functions are intended to be one-directional. That's why they're also called "digest functions". You're not getting your meal back after you've digested it.

Anyway, why are you scared of storing the keystore password in plain text? You can just run Tomcat under some service account and give only this service account read permissions to the configuration file.

If somebody with admin rights has bad intentions, or simply doesn't know what they're doing, you've already lost the battle, even if you DID encrypt the keystore password.

you know how those sec guys can get with their scans. I also get a little leery of asking network guys for specific access setting because I find myself upgrading Tomcat point releases a lot and deploy in parallel to old instance (ultimately removing the old) . I know what you're saying though, it's the only way. I've been reading about this for two days and encrypting the passwords in config files and key store(s) seems to come back to every security apparatus has to have an entry point vulnerability. I once heard the director of "The Blues Brothers" say that for the mall scenes, they hired security guards to watch over the merchandise then had to hire guards to watch the guards.

I also get that Tomcat running as a service on startup also sets up the TLS and connector stuff so it needs to access the clear passwords sans human intervention.

But at the same time, password protecting the key store, then storing the password out there seems redundant.  Why not just use open pem files instead of creating a key store, for example?

So i looked at the Tomcat disgest.bat thing to see if maybe it could use a SHA 256 algorithm or whatever, to work like a complicated authentication system..

1) salt/hash any passwords you want.
2) stores the salt/hash/clear pw mapping in some secret protected, self-encoded/decoded "place" or whatever...in some lib ...some "table"...
3) you toss the salted hash password into corresponding xml file
4) then on any request, basically during service startup but on user requests as well, maps the salted hash in the whatever xml to the clear password and shoves that into the access request
5) But in any case, the digester looks like it only works on tomcat-users.xml and users entering pw's.
6) I also think for @2 above, as you said, the digester just spits out the hash, you'd need an external db in a realm to store the salt/hash/real mappings.

Have you tried that Tomcat Vault? I was about to go down that rabbit hole but not liking how "obscure" this looks....  thanks so much.

Thomas Griffith wrote:But at the same time, password protecting the key store, then storing the password out there seems redundant.  Why not just use open pem files instead of creating a key store, for example?

Because KeyStore is idiomatic in Java. Most Java application servers provide a way of configuring a key store to use for stuff like TLS. Besides, a KeyStore can hold more than just a single certificate. It can hold multiple certificate chains, private keys and secret keys. If you wanted to use different certificates or keys for different purposes, you don't need to have all of them strewn about as different files.

2) stores the salt/hash/clear pw mapping in some secret protected, self-encoded/decoded "place" or whatever...in some lib ...some "table"...

Your logic breaks down here. How are you going to keep this "secret protected place" secret and protected?

Have you tried that Tomcat Vault? I was about to go down that rabbit hole but not liking how "obscure" this looks....  thanks so much.

Just consider this: You're trusting a third party application to keep your password safe, but not the operating system that it's running on?

In short, just put the password in the server.xml file and let your OS protect it.

Hello. I decided not to mess with those passwords (hashing, xor, etc) as per the advice given although I messed around some with obfuscation just in case sec comes down with something. It's a huge risk with locking yourself out, I think, the more cryptic ya try to get.

One thing I want to do with the key store is read the expiration date and start serving up warning notices starting about 3 months out. I've seen some examples and I have the pem file open with the secret key and server, intermediate, root certs. I've seen this code and I'm kinda wondering what exactly is enumerated in this file..

Enumeration aliases=keystore.aliases(); for (; aliases.hasMoreElements();) {   String alias=(String)aliases.nextElement();   System.out.println(aliases);   certExpiryDate = (x509Certificate) keystore.getCertificate(alias)).getNoteAfter();

The pem....

Bag Attriutes... ---BEGIN PRIVATE KEY---- .... ---END PRIVATE  KEY--- Bag Attributes ---BEGIN CERTIFICATE--- ... ---END CERTIFICATE--- Bag Attributes ---BEGIN CERTIFICATE--- ... ---END CERTIFICATE--- Bag Attributes ---BEGIN CERTIFICATE--- ... ---END CERTIFICATE---

The code goes through one enumeration, not four (key + each cert i the hierarchy) and works but I don't know why. The System.out prints alias - 1. Is it because there are no aliases in here?

when I use keystore.getCertificateChain(alias) it scrolls through the three certificates. Still not sure what the alias is and why it's the point of reference for these methods.

Another approach would be to not deal with the keystore at all, and possibly perform your test on a different platform than where the server is running.  Since the server's X509 certificate is freely offered to the client during the TLS negotiation, you can attempt to make a connection to the server, grab the certificate, and then check the certificate's expiry date/period.

Here's a an example written in bash using openssl, but it could easily be done in Java as well:
#!/bin/bash site=$1 seconds_per_day=$((3600 * 24)) check_seconds=$(($2 * $seconds_per_day)) echo "" | openssl s_client -connect $site | sed -ne '/BEGIN CERTIFICATE/,/END CERTIFICATE/p' | openssl x509 -noout -checkend $check_seconds is_valid=$? if [ $is_valid -eq 0 ]; then  echo "certificate good for at least $2 more days" else  echo "certificate will expire in $2 days or less" fi exit $is_valid
./cert_check www.google.com:443 60 depth=3 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA verify return:1 depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1 verify return:1 depth=1 C = US, O = Google Trust Services LLC, CN = GTS CA 1C3 verify return:1 depth=0 CN = www.google.com verify return:1 DONE certificate will expire in 60 days or less
./cert_check www.google.com:443 30 depth=3 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA verify return:1 depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1 verify return:1 depth=1 C = US, O = Google Trust Services LLC, CN = GTS CA 1C3 verify return:1 depth=0 CN = www.google.com verify return:1 DONE certificate good for at least 30 more days

wow, that's pretty interesting because the one sticky part I was hitting (other than trying to figure ot what exactly an alias is in a Key store) is basically having to hard code in the key store path into the code. I was initially surprised the exp date would be accessible but thinking about it, the browser has to negotiate/determine all that during the TLS handshake and working it's way up the cert chain until it can compare root with it's trust store.

Is the alias implicitly assigned, even if it's null or blank, to a private key and associated key chain at creation?

Thomas Griffith wrote:Is the alias implicitly assigned, even if it's null or blank, to a private key and associated key chain at creation?

The alias should be defined when when the entry is added to the key store.  Depending on the tool/API you used to add the certificates to the store, specifying an alias may have not been mandatory.

Really though, do you care which certificate in the store in for the host and which are for the intermediates?  If any of the certificates in the chain are about to expire, you will need to take action (plus, it in unlikely have the intermediate certificates will expire before your host certificate).

Here's some proof-of-concept code to check using Java.  Since you are using Java 8, you won't be able to use the new built-in HttpClient, but you should be able to do something similar with other clients (Apache HTTPClient, OkHttpClient, etc.).
import java.io.IOException; import java.net.URI; import java.net.URISyntaxException; import java.net.http.HttpClient; import java.net.http.HttpRequest; import java.net.http.HttpRequest.BodyPublishers; import java.net.http.HttpResponse.BodyHandlers; import java.security.cert.CertificateExpiredException; import java.security.cert.CertificateNotYetValidException; import java.security.cert.X509Certificate; import java.util.Arrays; import java.util.Date; import org.junit.jupiter.api.Test; public class CertCheckTest {    static final long MILLIS_PER_DAY = 24 * 3600 * 1000;    final String site = "https://www.google.com";    @Test    void should_be_valid() throws URISyntaxException, IOException, InterruptedException {        var days = 10;        var isValid = willSiteCertBeValid(site, days);        System.out.printf("Will %s be valid in %d days?: %s%n", site, days, isValid);    }    @Test    void should_be_invalid() throws URISyntaxException, IOException, InterruptedException {        var days = 400;        var isValid = willSiteCertBeValid(site, days);        System.out.printf("Will %s be valid in %d days?: %s%n", site, days, isValid);    }    boolean willSiteCertBeValid(String site, int days) throws URISyntaxException, IOException, InterruptedException {        var client = HttpClient.newHttpClient();        var request = HttpRequest.newBuilder(new URI(site))                .method("HEAD", BodyPublishers.noBody())                .build();        var response = client.send(request, BodyHandlers.discarding());        var certs = response.sslSession().get().getPeerCertificates();        var checkPeriodMillis = days * MILLIS_PER_DAY;        var checkTimestamp = System.currentTimeMillis() + checkPeriodMillis;        var checkDate = new Date(checkTimestamp);        var invalid = Arrays.stream(certs)                .filter(cert -> "X.509".equals(cert.getType()))                .map(X509Certificate.class::cast)                .map(x509 -> {                    try {                        x509.checkValidity(checkDate);                    } catch (CertificateExpiredException | CertificateNotYetValidException e) {                        return Boolean.TRUE;                    }                    return Boolean.FALSE;                })                .anyMatch(v -> v);        return !invalid;    } }mvn -q verify -Dtest=CertCheckTest Will https://www.google.com be valid in 10 days?: true Will https://www.google.com be valid in 400 days?: false

I like it, Ron.

Ron McLeod wrote:
Really though, do you care which certificate in the store in for the host and which are for the intermediates?  If any of the certificates in the chain are about to expire, you will need to take action (plus, it in unlikely have the intermediate certificates will expire before your host certificate).

yeah, I was doing some messing around and parse all the certs in the hierarchy (leaf, intermediate, root) in the key store and spit out their expiration dates. I have three leaf certs on three different servers, but the intermediates do have different expiration dates (root of course the same), But the leaf exp dates all come before the intermediates.

I'm going to check out the Java 11 Httpclient but might be stuck with 8 for now (where I want to host the scheduled procedure is on 8).