[SERVER-2205] Ensure Server CA can use a CRL path that contains multiple PEM encoded CRLs Created: 2018/05/09  Updated: 2018/09/19  Resolved: 2018/06/28

Status: Closed
Project: Puppet Server
Component/s: None
Affects Version/s: None
Fix Version/s: SERVER 6.0.0

Type: Improvement Priority: Normal
Reporter: Justin Stoller Assignee: Tony Vu
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relates to SERVER-2216 Investigate potential leiningen bug Resolved
relates to SERVER-2215 Upgrade cljs workflows to use updated... Closed
Epic Link: Robust Intermediate CA
Team: Server
Release Notes: Bug Fix
Release Notes Summary: Server side fixes for finally, fully supporting intermediate CA-ness:
with this CRL chains will be persisted when revoking certs.
QA Risk Assessment: Needs Assessment


We need to make sure that Puppet Server can actually handle the CRLs that we are expecting it to. This will most likely entail updating our calls of pem->crl to be the newer pem->crls. And updating the revoke behavior to write out the additional crls in the chain when replacing the current crl file.

Comment by Justin Stoller [ 2018/05/09 ]

I'm going to need to spend a day just on the testing of this. But I think I have the tradeoffs in the approach outlined in above in this PR:

Comment by Maggie Dreyer [ 2018/05/22 ]

I merged the jvm-ssl-utils PR, I think that library needs to be released now and updated in clj-parent, then that needs to be released and updated in puppetserver before the puppetserver PR can be merged.

Comment by Justin Stoller [ 2018/05/22 ]

I've released ssl-utils 1.0 to clojars. ssl-utils is brought into puppetserver via clj-parent and since our last update clj-parent has released 2.0. I'm currently looking into updating to clj-parent 2.0 and then adding ssl-utils to clj-parent 2.0.1 rather than branching 1.7.x and targeting that. (We should upgrade to clj-parent 2.0 prior to releasing 6 anyways.)

I'm currently having a bunch of issues with clj-parent 2.0 and will time box it.

Comment by Maggie Dreyer [ 2018/05/22 ]

I do think it's a good idea that we get on clj-parent 2.0. If it ends up being more of a hassle, we should still do it, but probably file a stand-alone ticket to track the work.

Comment by Justin Stoller [ 2018/05/24 ]

I spent one day fruitfully upgrading our dependencies and another day accidentally unfruitfully upgrading/fixing bugs. I think I've found the bottom of the rabbit hole but I think it would take a couple days, maybe more, to fix them properly. I've put them into tickets and linked them above.

Comment by Maggie Dreyer [ 2018/05/24 ]

Do you want to do those tickets now as a blocker to this, or branch clj-parent?

Comment by Justin Stoller [ 2018/05/24 ]

I think I can leave the cljs work behind for now. Our dev env for it is broken, but it doesn't seem to work prior to upgrade either. I think the cljs work will be a blocker to Java 9 support though. I have a work around in our project.clj for what appears to be a lein bug and that will unblocked me. Other teams may need a similar work around.

So I'm going to go ahead and not branch, but note that we're carrying forward additional technical debt that needs to be resolved pre-Puppet 6.

Generated at Sun Oct 20 20:13:48 PDT 2019 using JIRA 7.7.1#77002-sha1:e75ca93d5574d9409c0630b81c894d9065296414.