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:
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.
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.
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?