Oh boy, this has been a rollercoaster of emotions. But guys…we made it. We have finally, and definitively answered what happens to WinRM with HTTPs when certificates expire. If you’re curious about why this is a big question, see my previous posts on this topic.
Up until now, I’ve been able to say, conclusively, that WinRM generally seems to work, even as Certs expire and are renewed. But I’ve never known why: did WinRM automatically update the certs? Does Windows just not care about certs? What is the purpose of life?
Well, I can now shed light on at least some of those questions. I knew what I needed to do
Record a WireShark transfer and extract the certificate to tell definitively, which cert is being used to validate the session. Then we’ll know what happens.
Setting the stage
Two VMs, one domain. Server 2016 server, connected to from a Server 2012 R2 client. Newly created WinRM capable Certificate Template available to all domain members with a 4 hour expiration and 2 hour renewal period.
With the stage set, and the cert was present on both machines, I ran winrm quickconfig -transport:https on each, then made sure they could see each other, and remoted from one into the other. I recorded a WireShark trace of the remote session, uh remoting, then ran a command or two, then stopped recording. Then I opened the trace.
Recently I’ve gone a bit of a blog and twitter hiatus, because the FoxDeploy family just inherited a new child-object! Born February 2nd at 2:02 AM, I had my first son!
I promise I’ve got some nice posts on the way, including the anticipated Part V of my GUI series, as well as Part V of the DSC guide…including a new tool I’ve been working on with some help from my friends in Redmond…
System Center Orchestrator–formerly Opalis Orchestrator– and now lovingly called SCORCH by its fans is a powerful automation tool, but there are a lot of gotcha’s that makes it difficult to begin rolling out in the environment.
For instance, it’s desirable to Return Data back from a Runbook either to a parent runbook, or to Service Manager or another system to act on the results. As an example, imagine a runbook that can fork in many places and then return an exit code that we then send off to a parent runbook to register as an Operations Manager event, or to send in an e-mail. There’s lot of options. Well, even with this common scenario, people still run into a brick wall when they experience the following
When a runbook has valid data pushed to the SCORCH Databus, adding a Return Data step results in a blank window like the following.
I’ve recently been in the process of migrating my blog off of WordPress.com hosting to my own WordPress.org account. I tried a few things, a number of which did not work well, and I hope to help you avoid them if you try the same thing too.
After installing WordPress on a localhost / Linux LAMP setup (Linux Apache MySql PhP) you’re prompted for credentials when uploading content or plugins
This one is super annoying. You’ll basically see a message like this whenever you try to install a new plug-in, and have to put in your Linux credentials.
–Whats going wrong
What happens here is that if you follow the instructions in this page for setting up WordPress on a LAMP stack, you’ll end up with WordPress installed to /var/www and all of the files and folders there owned by your user account. This means that when you try to upload files, Apache, the Linux Web Service, which runs with the user account www-data will not have any permission to this path. Hence the prompt for credentials.