- January 29, 2016 at 2:55 pm #34581
Question is in the title but to restate: is it possible to have multiple certificate thumbprints defined in the Local configuration of a node?
The scenario is basically not unlike ADFS: being able to decode from multiple certs makes it easier to transition nodes without interruption when certs are about to expire: I can add a newly issued certificate and the existing mof will continue to run while I go and trigger the build-bot to generate new mofs (or even just wait for said bot to trigger on it's schedule and let the cert age out).
But I can't find any documentation to support if this is even possible. If not ... off to the feedback forum I guess...
Larger picture for those currious:
1. Using Microsoft PKI with templates to auto issue-renew computer certificates.
2. We already have a provisioning script that looks for the computer cert with the latest expiration date and copies it into a folder for the build-bots to use during mof generation.
3. These certs expire (suprise), so we are looking into automated options for "flipping" the certs over ... but have to deal with a "delta period" between certs being changed and the next mof generation cycle.
Now I could "flip the script" and have the build-bot "reach out" and update each node after a direct scan but , as you could imagine, that scales very poorly. But then I'm left with that delta problem.February 1, 2016 at 12:25 pm #34665
I don't think so. Right now, there isn't really a way to name the certificates so that you could identify them, or to tell the node which cert was to be used for which. It isn't reasonable to tell the node, "here's ten certs, when you need to use one, just try them all until one works," so without some means of identifying and specifying, it wouldn't work well. Not that what you're asking for is a bad idea, just that there isn't any scaffolding in place to make it practical right now.
But I'm not sure multiple certificates is actually the answer to the problem. You're essentially asking the LCM to incorporate more logic, but really, what you need is more back-end logic. This just highlights the lack of tooling around DSC right now.
I think what you really want is to check that expiration date when you're generating the MOFs, and never rely on a certificate whose expiration will occur between build cycles. E.g., use back-end logic to eliminate the delta period. Get those two processes better aligned.
This is an instance where a self-modifying node-side configuration script might come in handy, rather than just pushing out MOFs. Hmm.
Anyway, to answer your question succinctly, no. But I'm not sure the ability you're asking for is what really solves the problem in the best and most scalable way. Less logic on the node is sort of the ideal, so not having to have the node worry about certificates is the ideal. But there's no better prepackaged solution, either.February 1, 2016 at 12:30 pm #34666
I don't think certificate thumbprints get checks in the pre-scan on the LCM. That means, in theory, you could deploy a MOF to which the LCM didn't have a valid cert, and the LCM would process it up until it needed the cert and exploded.
Meaning, you could potentially build a certificate-pulling DSC Resource, have it run first, having anything else needing a cert depend on it. It could accept a property that tells it which cert should be local, and its Set() method would actually make that happen if it hadn't.
So your bots would build the MOF, and the MOF itself – via that DSC Resource – would "know" which certificate was needed to execute the MOF, and have the ability to go get the certificate if needed. You could almost generate a new certificate every cycle if you were maniacal or something, and it'd work. In that instance, the bot would be telling the node which certificate to use, and the node would be responsible for getting it.February 1, 2016 at 1:22 pm #34669
Reading your post a few times over I *think* I may have a decent answer, but it will need some testing. Plus I'm still a PSNoob in a lot of ways so sorry if I completely mangle your idea.
Like you mentioned: bit more logic on the back end may be needed... which means a lot more testing 🙂
Laying out the theory to see if it makes sense:
1. there is a share that exists that contains every public cert named after each node. This was/is populated during initial node configuration anytime a new node comes online.
2. The current build-bot actually looks for the presence of the certificate in said folder, and if it exists it modifies the configurationdata hashtable while it's in-memory and adds certificate information to each node before running it through the configuration.
Because selecting the certificate to use is removed from anything "hard coded" in the configuration or configurationdata... I should be able to add logic that checks the expiration date, and if it's less than (whatever the build interval is) it pulls the current certificate from the issuing CA (so I'm only reaching out to one box and not making hundreds of connections while praying the VPN/firewall gods are kind), and continues on it's merry way. I then just need to re-read the thumbprint and update the dsclocalconfiguration meta mof. Wont even need to build a full resource that way I think.
You've given me a lot to think about. thank you.
PS. Anyone reading this out of curiosity, I run a "lab version" complete with blog which I keep synced up to github and anyone who wants to can read/steal/mock what I'm doing. Hit me up and ill share the github page as well as blog of my ramblings.
You must be logged in to reply to this topic.