CAs should not expire before their issued entities about django-ca HOT 5 CLOSED

This could be solved easily...

What might be the best way to handle this? Raise a warning and fail, set the expires date to the same as the parent, or raise a warning only if the user has specified an expiry (set to parent expiry if not explicitly set)?

from django-ca.

Hi,

Sorry I didn't attend to this issue for a while. I was held up in other projects. In any case, I didn't give it much importance since initial research into the TLS specs showed that this is not actually an error.

After no longer being held up by other projects and some more research, I'm sure it actually is an error. I'm in the process of implementing this now. I've settled for this behavior:

• For creating child CAs, the maximum expiry is silently set to that of its parent. The reason is that any default of X days is automatically after that of the parent a day after issuing the parent.
• For child certificates, I throw an error if the default or whatever the user specifies is after the CAs expiry.

This means that with a default of a year and a CA expiring in 10 years, you'll be able to silently issue certs for nine years, in the tenth year you'll get errors with the default expiry. This seems reasonable because an expiring CA is something you really should take care of. In the meant time, you can issue shorter-lived certs if you explicitly want.

from django-ca.

PS: If there's strong objection to that behavior please let me know. I'll definitely consider it.

from django-ca.

That seems the most sensible approach 👍

from django-ca.

I've just tagged version 1.4.0 which implements this behavior (and has a few new features). Please just open a new issue if you find any problems!

from django-ca.