Using the auto generated certificates causes "Bad Key" issue if the certificates are used again. (On Premise 1.1)
When "reusing" the certificates from "auto generation", a second install creates an error.
Created and configured Service Bus farm management database.
Created and configured Service Bus gateway database.
Creating default container.
Steps to reproduce.
Use Configuration Wizard or Powershell (New-SBFarm and Add-SBHost ) to Install Service Bus 1.1 using "Auto Generate" certificates. (-CertificateAutoGenerationKey switch)
Remove from Farm this machine. (Leave the auto generated certificates "in tact" on the machines).
Use Configuration Wizard or Powershell (New-SBFarm and Add-SBHost ) to Install (a second time) Service Bus 1.1 NOT using "Auto Generate" certificates. (-FarmCertificateThumbprint and -EncryptionCertificateThumbprint switches) Use the Thumbprints of the certificates that were generated above.
You'll get an error
Can anyone confirm this as a bug?
The problem is that this kills my disaster recovery attempts. (I need to be able to reinstall the certificates on a "new" machine if my original machines go kaputt)
I've also tried making my own self signed certficates, but that's another story. (The client machine refuses to talk to Machine2-5 of the Farm). (I mention this because I think that would be a suggestion ..... ).
This seems very easy to reproduce. I hope someone will look at it soon.
My guess is that you are missing one of these flags on the "encryption", aka (Subject = 'CN = AppServerGeneratedSBCA') certificate.X509Extension.X509KeyUsageExtension.KeyUsages='CrlSign, KeyCertSign'
The below would be the flag-setter when using makecert.exe. (No idea how the "auto generate" certs are being created).
For future readers.
After getting stone-walled with the Auto-Generated certificates, I was finally able to get my "home made" certificates working.
The "trick" was mimic'ing the Auto-Generated certs. But in one very important place
So after looking at the certificates that Auto-Generate created, I discovered that the “Subject Alternate Name” was set to
This is what allowed my client to talk to MachineTWO.fullyqualified.domainname.com even though the certificate was named MachineONE.fullyqualified.domainname.com
I have posted about it here:
And I have BouncyCastle code to create the certificates. PS "makecert" does not support Subject Alternate Name, thus the need to move to another way.
BUT PS. This would not be needed if the "Bad Key" error would be fixed. Please (Microsoft moderators), make sure someone is looking at this. It is a simple fix to add the mixing "flag" in the Auto-Generate "Make Our Certificates" code that got overlooked.
- Proposed as answer by Sheethal J SMicrosoft contingent staff, Moderator Monday, November 07, 2016 7:23 AM