BUG: Using ConfigurationNames generates a weak certificate
If a Node is configured using a RegistrationKey so that ConfigurationNames can be used, then the CertificateID attribute is ignored under the ConfigurationRepositoryWeb block, and instead a self-signed certificate is generated called "DSC-OaaS".
This certificate is used for both client authentication to the pull server as well as encrypting configuration Mofs at rest on the server host.
The problem is two fold:
Becuase the CertificateID gets ignored when using CONfigurationNames, admins cannot control the key length or encryption of the files.
The certificate generated is a SHA-1 1024bit length. This is completely unacceptable as 1024 went out of use years ago, and SHA-1 is getting retired this year as an encryption standard.
Please allow administrators to select the certificate for use and NOT force a weak self-signed certificate.
3 comments
-
Joel Cook
commented
I second this, not being able to manage this certificate on the nodes is going to be a show stopper for us as inserting those self-signed certificates into the local machine store breaks other internal processes we have that rely on internal certificates issued from our CA. If we had the ability to control which cert was used with ConfigurationNames for authentication, this would not be an issue
-
Justin King commented
Thank you for the update! I figured out later that it's not used for encryption after deeper testing, sorry about that part being false and I"m glad to hear it's an official bug to be only 1024.
I would like to clarify, however, that while it IS only for authentication, it's non-configurable when using configurationnames. If I use a ConfigurationID, I can then specify the CertificateID in the Configurationserverweb block and authenticate with whatever certificate I desire. As soon as I go to configurationnames .... I have to use the self-generated certificate "DSC-OaaS" and that property becomes illegal to specify.
I find the lack of options a bug as well, as my ability to control this behavior changes.
I have more details posted in a blog:
https://transformingintoaservice.wordpress.com/2016/03/09/wmf5-dsc-and-dsc-oaas-certificates/ -
Thank you for the update! I figured out later that it's not used for encryption after deeper testing, sorry about that part being false and I"m glad to hear it's an official bug to be only 2014.
I would like to clarify, however, that while it IS only for authentication, it's non-configurable when using configurationnames. If I use a ConfigurationID, I can then specify the CertificateID in the Configurationserverweb block and authenticate with whatever certificate I desire. As soon as I go to configurationnames .... I have to use the self-generated certificate "DSC-OaaS".
I find the lack of options a bug as well, as my abilty to control this behavior changes.