Wizard78
Contributor
Contributor

vSphere 6.0 U3 Custom Certificates instalation error: Previous Machine_SSL_CERT Subject alternative name does not match new Machine_SSL_Certificate Subject alternative name

We have setup a testing environment to perform an upgrade from vSphere 5.5 to 6.0 U3

Have updated one vcenter from 5.5 to 6.0 U3 and try to test custom certificates. All infrastructure servers are installed on Windows 2008 R2 Standard (Vcenter, AD/CA, SQL)

Tried to follow this article Replacing a vSphere 6.x Machine SSL certificate with a Custom Certificate Authority Signed Certifica...

We have created certificates template using this article as guide Creating a Microsoft Certificate Authority Template for SSL certificate creation in vSphere 6.0 (211...

Creating a new template for vSphere 6.0 to use for Machine SSL and Solution User certificates

    Connecting to the CA server, you will be generating the certificates from through an RDP session.

    Click Start > Run, type certtmpl.msc, and click OK.

    In the Certificate Template Console, under Template Display Name, right-click Web Server and click Duplicate Template.

    In the Duplicate Template window, select Windows Server 2003 Enterprise for backward compatibility.

    Note: If you have an encryption level higher than SHA1, select Windows Server 2008 Enterprise.

    Click the General tab.

    In the Template display name field, enter vSphere 6.0 as the name of the new template.

    Click the Extensions tab.

    Select Application Policies and click Edit.

    Select Server Authentication and click Remove, then OK.

    Note: If Client Authentication exists, remove this from Application Policies as well.

    Select Key Usage and click Edit.

    Select the Signature is proof of origin (nonrepudiation) option. Leave all other options as default.

    Click OK.

    Click the Subject Name tab.

    Ensure that the Supply in the request option is selected.

    Click OK to save the template.

    Proceed to Adding a new template to certificate templates section in the article to make the newly created certificate template available.

On Vcenter server 6.0U3   (Embeded PSC) we run the certificat manager tool to generate CRS records, we have used option 1 and 5 as our goal is to use custom certificates.

We followed this article to get certificates from Microsoft CA  Obtaining vSphere certificates from a Microsoft Certificate Authority (2112014) | VMware KB

Note: this is a simple lab environment so there is no intermediate CA only the root one on  Windows 2008R2

We copied certificates to the new vcenter and tried to import Machine SSL certificate and got the above error

Previous Machine_SSL_CERT Subject alternative name does not match new Machine_SSL_Certificate Subject alternative name

We tried to use san:dns=fqdn..... using attributes box from CA to specify a unique SAN but got same error

Have attached the certtool.cfg file and certificate manager log.  Any help would be appreciated

12 Replies
WNBJoshMcCown
Contributor
Contributor

I just wanted to chime in on this as we ran into the same issue in our environment... after raising a case with support, it was discovered that the DNS name in the Subject Alternative Name field is case sensitive and must match the SAN from old.  When generating the csr, I had filled in everything with lowercase when my self signed cert was uppercase.... regenerated the csr to match and we were all set.

Hope that helps anyone else out there who may stumble into this.

VeeJee
Contributor
Contributor

Hi,

Got the same issue with VCSA6u3. I found KB2150267 but it offers not a solution.

Everything in the new certificate matches with the current certificate. We also noted that case sensitive everywhere matches. In our current certificate is not an e-mail address specified. If we created a new csr and leave the optional e-mail address blank, we see the following in the "Subject Alternative Name"  it always contains "RFC822 Name = email@acme.com". And that's exact where the new certificate differs with the current certificate.

Does anyone have a solution for this issue? I've already opened a support case.

Cheers!

0 Kudos
Chapstickk
Contributor
Contributor

Did you ever get to the bottom of this?  We are running 6U3 - external PSC and are trying to update our VCSA cert with custom signed one.  Currently the appliance is using a PSC CA which contains RFC822 Name=email@acme.com -  This field does not exist on our custom signed certificate and we are getting the error.

Status : 10% Completed [Replacing Machine SSL Cert...]

Previous MACHINE_SSL_CERT Subject Alternative Name does not match new MACHINE_SSL_CERTIFICATE Subject Alternative Name

Have confirmed case is correct so believe it has something to do with this email address.

0 Kudos
rcramirez
Contributor
Contributor

I am having similar issue on VCSA 6.5

Previous Machine_SSL_CERT Subject alternative name does not match new Machine_SSL_Certificate Subject alternative name

The current Subject alternate name have

DNS=server.domain.com

DNS=server

IP Addresses=10.10.10.10

And the one we want to install has

DNS=server.domain.com

so we are missing 2 subject alternate names

But we cant create custom Certificates with hostname

0 Kudos
Chapstickk
Contributor
Contributor

It sounds like I had the same issue as you.  I ended up resolving the issue I was experiencing by generating a new CSR and self signed cert (option 3?) and leaving the IP address out which likely should not have been there in the first place.  Once this was done I was able to generate a new CSR and externally signed cert.  

0 Kudos
ivanerben
Enthusiast
Enthusiast

Just hit this issue. Oh come on vmware, bugs bugs and bugs!!!!! In simple things!

0 Kudos
erwinbre
Contributor
Contributor

Hi Chapstickk,

Can you elaborate please? I'm facing the same problem.

I don't quite understand how you got it to work.

For Subject Alternate Name I want only the DNS name to be visible. And not the IP or RFC email

Thanks!!

Erwin

0 Kudos
mtbrad
Contributor
Contributor

I hope this helps, I was having the exact same issue and nothing on the internet was leading me in the right direction.

It appears that there's actually multiple locations as to where the certool.cfg is located. Most documentation points to /usr/lib/vmware-vmca/share/config, but when using the certificate manager (/usr/lib/vmware-vmca/bin/certificate-manager), it doesn't pull from that .cfg file. I ran a find command to see if I could figure out where it was pulling the configuration file from, and it apparently keeps a temporary one in /var/tmp/vmware. I edited that file regenerated the default certificate (using option 4 in the certificate manager), but it still wasn't working, which meant it was still using a different config file. So, I decide to actually browse to /var/tmp/vmware and lo and behold there's other config files (MACHINE_SSL_CERT.cfg, machine.cfg, root.cfg). I edited these (mainly commenting out the email and IP address lines), regenerated the default certificate (using option 4 in the certificate manager), and the SAN now only had my one DNS entry in it and the email and IP address had disappeared. Once you get to that point, you can then run the certificate manager again and import your custom certificate, key, and cert chain that only has the one DNS entry for the SAN.

I should add this is on the assumption that you've already used option 1 to generate your certificate. If you have yet to do that, then, I assume, it creates the MACHINE_SSL_CERT.cfg, and others, from your certool.cfg file that's located in /usr/lib/vmware-vmca/share/config. If you've already commented out the IP and email in that file, it would work, but in my scenario, and I assume yours, you'll be looking for the MACHINE_SSL_CERT.cfg, machine.cfg, and root.cfg files. It may only require editing the MACHINE_SSL_CERT.cfg, but I changed those three specifically. Feel free to reply with your results. Hope that helps!

0 Kudos
AndreRi
Contributor
Contributor

Hi,

I had a similar issue. I wanted to replace the default cert with one of a public trusted CA.

The new cert had Subject Alternative Names like:

hostname.domain.tld

cname.domain.tld

The initial cert had SANs like:

hostname

ipv6address

and others

I disabled the SAN check by modifying the python code of the certificate manager.

The certificate manager file is located here

/usr/lib/vmware-vmca/bin/certificate-manager

I just uncommented line 594 and line 596 (see blow)

#        if var.strip() in ['1']:

#            iscomparerequired = compare_certificate_san(oldcert, cert_file)

After that it worked for me. (You can also copy the attached file).

Use this advice at your own risk. Backup the file before and create a snapshot of your vCenter.

Kind regards

André

stiftelsen
Contributor
Contributor

Thank you André!

Your solution worked for us after trying to import a custom certificate from Comodo. This was done on vCenter 6.5, worked like a charm!

0 Kudos
fm2ahmed
Contributor
Contributor

Hi AndreRi,

Worked like a charm for vCSA6.5. Thanks mate!!

Regards,

Farooq Ahmed

0 Kudos
GregoryI
Contributor
Contributor

Hello AndreRi,

tested your solution on VCSA with external platform service 6.7 and it worked like a charm!

Many thanks!!! Saved me a lot of time with support and investigation.

Best Regards.

0 Kudos