ConfigurationNames generates a weak certificate

EDIT: As this thread got pushed to the top, I felt it important to put a fresh summary of findings here so people don’t have to read through everything:

Summary:

  1. A new DSC-OaaS certificate is generated every time you submit an LCMConfiguration that contains a registration key. Submit the same config 5 times … you get 5 new certs.

  2. You cannot submit a configuration that uses both a registrationkey and certificateID in the configuration block (settings block is ok). If you submit a certificateID later, the setting is ignored as long as configurationnames are in use.

  3. DSC-OaaS does not have encryption defined for key usage, so it CANT be used for encryption. This was mis-diagnosed earlier, but it appears to only be used as an authentication piece.

Putting all the behavior together it seems that this certificate has one sole use: as a 2nd factor to identify a computer in conjunction with AgentID. As it doesn’t appear to have any use outside of this very specific case, I feel a little better about it being a weak certificate (1024bit SHA-1), but would still love to be able to configure this.


So I noticed that when you configure nodes to use configurationnames, a certificate gets generated on the client called “DSC-OaaS”. From checking the logs it looks like it uses this certificate moving forward after registration to contact the pull server. Crawling through the logs, anytime get-dscmodule, get-dscdoument, etc. is called, the certificate is used. It looks like it’s only used for signing as it only gets generated when you register for configurationnames, and it doesn’t appear to be used in any kind of encryption during transit … BUT …

it’s only a 1024 SHA1 certificate. Is this configurable in any way? SecOps is pretty strict about these things (for obvious reasons), and I really don’t blame them.

Alternatively, is there any good published doumentation around the relationship of the AgentID and this certificate so we can feel a bit better abut it’s use?

No, there’s nothing published. Gimme some time and I’ll ask around.

If you created the pull server with a SSL certificate thumbprint, then the transit between the node and the pull server will use that.

Have you used AllowUnsecureConnection in the nodes’ LCM script by any chance ?

I think a little clarification may be in order.

I’m using 2048 SHA256RSA certificates all around, and I even re-issued the certs for the new “document encryption” advanced usage flag that WMF5.0 now requires in order to encrypt credentials. There is no un-encrypted traffic at any point in transit, nor is it set as allowed (the IIS pull-server doesn’t even have an un-encrypted port to listen on).

The “DSC-OaaS” certificate isn’t used for encryption at all … it’s created by the node specifically when you setup ConfigurationNames. If you watch the logs it seems it is only used as as identity or client authentication, not for any kind encrypted transit once authenticated. If you configure your nodes to use the ConfigurationID model, no certificate is ever created.

I’m assuming this is being used in conjunction with AgentID in some way like a sort of username/password combo (agentid and certificate together make for a solid authentication), but I’d like clarification as SHA1 certificates are generally a no-no unless I can confirm their role.

It sounds logically that it is being used as means of “identification” based on the AgentID.

Best way is to check after you registered a node successfully, go and delete that certificate and do some dsc commands and watch the logs.

This might as well be a bug or design thought for cases where SSL isn’t enabled Bad Bad thing and when it is they create it anyway but don’t actually “use” it.

That certificate is apparently the one being used to encrypt the in-place configuration files on the node. Yay encryption, I suppose, but SA1024 is kind of lame, and storing the certificate right alongside the encrypted documents is just useless. I’d bug this on UserVoice, frankly. I’ve no idea what the thought was.

But OaaS is definitely related to authentication, so it may have some other role as well.

This whole v5 release has been very frustrating :confused:

Thank you both for the followup.

Arie: Looks like Don caught what I missed: the final mof is in fact encrypted by the node, but not in transit from the pull rather in-place on the node. But to your original question on the testing: I already tested and confirmed if you delete the OaaS cert then authentication to the pull server fails citing the node is “unregistered”.

Don: I completely agree that this belongs as a bug on user voice (at least now as I understand it). I’m curious though, when I setup ConfigurationID it does not encrypt the mof that I can tell (I can easily open current.mof and read it without issues in the \configuration directory). I wonder if this is perhaps configurable and I’m missing something? I may experiment with this a bit more… for example I can specify the certificateID in two places in the LCM… I wonder how that impacts things…

OK “Fast testing” I think can confirm things:

If I configure a node using ConfigurationID, I get a distinctly different behavior vs. using a registration key.

Couple clarifications to anyone else browsing this thread: The CertificateID is configurable in two different configuration blocks, and these two attributes function differently: Incomplete Sample incoming simply for clarification:

#Compile Configuration for install
[DscLocalConfigurationManager()]
Configuration meta
{ 
        Settings
        { 
            CertificateId = "D3E2DDFB15474940F778C5DD0094AC88999B660F";
        }

        ConfigurationRepositoryWeb ConfigurationManager
        {
            ServerURL = 'https://dsc.contoso.com:8080/PSDSCPullServer.svc'
            CertificateID = 'D3E2DDFB15474940F778C5DD0094AC88999B660F'
        }
} 

The first “CertificateID” ID in the main configuration block is the “traditional” certificate used to decrypt passwords that are in the MOF file. This appears to function just fine.

The 2nd “CertificateID” in the ConfigurationRepositoryWeb block, however, does not. Or rather, it gets ignored under certain circumstances.

If you are using ConfigurationID, this 2nd entry determines both which certificate is used as a client authentication certificate with the pull node, as well as selects the certificate used to encrypt the entire mof configuration at rest on the node. Leaving this value blank doesn’t appear to have any negative impact, the mof is merely left in plain text on the node (the credentials are still encrypted).

If you configure a registationkey instead, however, the 2nd CertificateID gets completely ignored and a new self-signed certificate is generated caled “DSC-OaaS”. This new certificate is used in the exact same manner as listed above: it authenticates to the pull server as well encrypts the mof at rest using this new certificate.

As we seem to have no control over the creation or use of this certificate when using ConfigurationNames, combined with the fact that the encryption level is woefully inadequate … It’s bug-filing time.

Thanks again all for helping me sleuth this one out.

Hmm this gives me an idea…

Good detective work.

Try this, create a cert yourself with all the needed info with the same name and you’re desired encryption key and algorithm and all the enhanced usage needed and place it in the same store, then run the LCM script on that node.

I have a feeling it will not create a new one and use yours. If so that might ease the concerns of your secops until its fully addressed by MS.

It actually makes sense to use a cert like that in the case of ConfigurationNames as it means no matter how many values you put in the Names. All of them will be encrypted at mof generation and you wont need one cert per “partial” mof

I join Don’s comment though. Hard to “sell” dsc like this.

Would the two of you be willing to contribute to a DSC wiki, if I create one? I feel as if all this detective work should go someplace. I’m happy to organize it, if you can help me put together some concise statements of what we’ve found.

Sure thing. Thought that’s where the faq was going to be. Also forked the DSC docs last night to my github account to try and add content and fixes.

Problem is that without a clear reason and vision as to why ms choose to use for example that new cert the way they did, the wiki/faq would be more of a guess work/wish and not a formal reason.

Up for contributing, have already something about the new report server creation that I think has to go into the DSC docs anyway.

Don: More than happy to contribute!

Arrie: I’ll try to make a more formal test but anecdotal evidence suggests that a new cert is created everytime you push a meta configuration that has registrationkeys defined. I say this as I had to clean up 15+ DSC-OaaS certs (all self signed) when I first started testing this process as I didn’t notice at first.

Still … I may create one issued form the internal PKI just to see.

OK I did a a long collection of scree captures to show a bunch of testing I did. There are some misconceptions above I was able to clear up, and there may be more things to test … but I figured this was the easiest way so you guys could see exactly what I did and how I got where I am.

Summary:

  1. A new DSC-OaaS certificate is generated every time you submit an LCMConfiguration that contains a registration key. Submit the same config 5 times … you get 5 new certs.

  2. You cannot submit a configuration that uses both a registrationkey and certificateID in the configuration block (settings block is ok). If you submit a certificateID later, the setting is ignored as long as configurationnames are in use.

  3. DSC-OaaS does not have encryption defined for key usage, so it CANT be used for encryption. This was mis-diagnosed earlier.

Putting all the behavior together it seems that this certificate has one sole use: as a 2nd factor to identify a computer in conjunction with AgentID. As it doesn’t appear to have any use outside of this very specific case, I feel a little better about it being a weak certificate, but would still love to be able to configure this.

We have bug to update this self signed certificate to 2048 bit and SHA256. https://windowsserver.uservoice.com/forums/301869-powershell/suggestions/12840786-bug-using-configurationnames-generates-a-weak-cer We will have it addressed. That said this isn’t a security issue as the certificate is not used for encryption/decryption purposes

I was just about to post that my uservoice went from bug to planned :slight_smile:

I not-so-humbly disagree, however, that just because it’s not used for encryption immediately disqualifies it as a security issue. How is authentication not part of security?

Also, please be aware of the 2nd part of this issue: the lack of control. If I use ConfigurationID, the certificate used to authenticate with becomes configurable. This should remain the case even when using configurationnames.

@Justin - using ConfigurationId means you are in essence using a V4 pull server/protocol. V4 requires that you configure the certificate. Configuring certificates on a lot of nodes turned out to be a problem for a lot of customers (both DSC and others) and hence in V5 we went down the auto generate route

How does generating a certificate not used for encryption solve that problem? Managed certificates are still needed for credential encryption.

I agree managing certificates can be a challenge, but honestly: V5 only made it harder:

  1. I can no longer “pull” meta-configs from a pullserver so I can’t manage certificateID using the existing DSC framework.
  2. I can’t configure CertificateID per configuration, it’s still done “all or nothing” in the LCM agent which either forces me to go back to ConfigurationID (so each node can use unique certificates that are uniquely compiled and meet security concerns) or forces me to standardize all my configs around a single, exportable certificate (compromise one box and I have the public/private key for all configurations).
  3. I now have a NEW certificate to manage called DSC-OaaS because this one does not auto renew. (Please let me be wrong here, but judging by current AA-DSC limitations I don’t think I am).

So the answer to clients thinking certs were hard to manage was you gave them more certs to manage? Or is this step one in an eventual plan to make the entire process actually self-managed like in Puppet (please let the later be true)?

Sorry if this comes off as aggressive, but it sometimes feels like Microsoft isn’t making a distinction between “making the framework easier to manage” and “making the framework easier to integrate into management solutions”, which aren’t really the same thing.