search

CaliDog / EasySSL

SSL certificate parsing for humans
MIT License
36 stars 19 forks source link

Support GeneralizedTime ASN.1 types in the validity field #4

Closed ahovgaard closed 5 years ago

ahovgaard commented 5 years ago

This allows validity dates beyond 2049. If a certificate has no well-defined expiration date, the notAfter date would likely be set to the generalized time 99991231235959Z (c.f., RFC5280). Another option would be to have an atom like :no_expiration to indicate this instead of the Unix epoch time for the end of year 9999.

I wonder if we could use some existing Erlang functions or a library for parsing ASN.1 encoded values like these, rather than doing it manually.

Fitblip commented 5 years ago

Hey @ahovgaard!

Thanks for the PR :).

If a certificate has no well-defined expiration date, the notAfter date would likely be set to the generalized time 99991231235959Z (c.f., RFC5280).

I had no idea, interesting.

Another option would be to have an atom like :no_expiration to indicate this instead of the Unix epoch time for the end of year 9999.

I like this idea more since it conveys intent better than 99991231235959Z. What about other timestamps in that crazy range (say issued with a notAfter field set to something like Jan 1, 6550? Is that within RFC compliance? If it is I think we should handle it appropriately.

I wonder if we could use some existing Erlang functions or a library for parsing ASN.1 encoded values like these, rather than doing it manually.

I looked while building this since parsing ASN.1 (and OIDs) are super annoying, but wasn't able to find anything that looked promising. That's not to say it doesn't exist though :).

Also, do you mind adding a test for your PR?

ahovgaard commented 5 years ago

I like this idea more since it conveys intent better than 99991231235959Z. What about other timestamps in that crazy range (say issued with a notAfter field set to something like Jan 1, 6550? Is that within RFC compliance? If it is I think we should handle it appropriately.

I changed it to use :no_expiration if the expiration date is set to 99991231235959Z. Regarding far away timestamps, I do not see anything about these being handled specially in the RFC, except that dates up to year 2049 should be encoded using UTCTime and dates in 2050 or later should use GeneralizedTime.

Also, do you mind adding a test for your PR?

I added a certificate with expiration 99991231235959Z in DER and PEM format for the existing unit tests to verify. I also added another unit tests that verifies that this date is parsed as :no_expiration.

ahovgaard commented 5 years ago

Please let me know if there is anything else I can add. :)

Fitblip commented 5 years ago

Hey @ahovgaard - sorry about the delay! Didn't see your other message.

This looks great! Thanks for the excellent PR :)

Fitblip commented 5 years ago

@ahovgaard - things are now live and pushed to hex.pm!

https://hex.pm/packages/easy_ssl

You should be able to update your dependencies to point to {:easy_ssl, "~> 1.1.1"} and life should be good! :)