Goline Logo

News

  • Route RPKI validation April 1st, 2022
    RPKI is a security framework by which network owners can validate and secure the critical route updates or Border Gateway Protocol (BGP) announcements between public Internet networks. BGP is essentially the central nervous system of the Internet and one of its fundamental building blocks. The main function of BGP is to facilitate efficient routing between Autonomous Systems (AS), by building and maintaining the Internet routing table. The Internet routing table is effectively the navigation system of the Internet and without it, traffic would be unable to flow between its constituent networks. Unfortunately, routing equipment alone cannot distinguish between legitimate and malicious routing announcements,...
  • RIPE – Atlas Anchor February 17th, 2022
    We have become an even more integral part of the RIPE Atlas project by hosting an anchor, a device that allows for latency analysis of traffic between autonomous systems.https://atlas.ripe.net/probes/7073/RIPE Atlas anchors play an integral role in the RIPE Atlas network by acting both as enhanced RIPE Atlas probes with more measurement capacity, as well as regional measurement targets within the greater RIPE Atlas network. Anchors are able to perform many more measurements than a regular RIPE Atlas probe, and the large amount of data they collect is made available to everyone. In addition, anchors act as powerful targets that can...
  • MANRS June 20th, 2020
    GOLINE firmly believes in initiatives to protect networks, improve security and resilience of the global routing system. Therefore we decided to support the MANRS project and join as participants.Mutually Agreed Norms for Routing Security (MANRS) is a global initiative, supported by the Internet Society, that provides crucial fixes to reduce the most common routing threats. MANRS offers specific actions via four programs for Network Operators, Internet Exchange Points, CDN and Cloud Providers, and Equipment Vendors. Requirements for Participation Please read the full MANRS Actions document before applying. You can become a participant if you meet these requirements: You (or your company) support...

VMware vCenter: Previous MACHINE_SSL_CERT Subject Alternative Name does not match new MACHINE_SSL_CERTIFICATE Subject Alternative Name

Paolo Caparrelli VMware 22 June 2022

Installing custom certificates into vCenter 6.7

The main objective is to have a HTTPS connection with no errors like this:

  First of all, you will need three certificates in the following format: 

  • root.cer of the Root CA (it can be internal or external CA). If you have an intermediate certificate, you must join the two certificates. Please check this article to do so;
  • certificate.cer generated by the Root/Intermediate CA. This is the certificate with the DNS name(s) that you want to change in vCenter. Something like vcenter.domain.local;
  • certificate.key of the main certificate (this is the private key)
 
If you don't have this format extension, you can always use OpenSSL to convert them: Download
 
Here are some examples:
  • Convert PFX to CRT/CER with certificate and private key
openssl pkcs12 -in certificate.pfx -clcerts -nokeys -out certificate.cer
openssl pkcs12 -in certificate.pfx -nocerts -out certificate.key
  • Convert PEM to PFX
openssl pkcs12 -export -out certificate.pfx -inkey certificate.key -in certificate.crt -certfile CACert.crt
  • Convert to multiple formats using a WebTool


With this certificates you are ready to start:

     1. SSH to the vCenter server
     2. Run the following command to enable and access the Bash shell: 

shell.set –enable True
shell 

     3. In the Bash shell, run the following command to change the default shell to Bash:

chsh -s "/bin/bash" root

     4. Copy the three certificates to vCenter server with WinSCP or similar. Copy them to /root/cert/
     5. Return to the Appliance Shell by running the following command:

chsh -s /bin/appliancesh root 

     6. Enter the following command to manage the certificates

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

     7. Choose option 1
     8. Provide the username and password of vCenter administrator
     9. Choose option 2
   10. Enter the full path to the main certificate.cer
   11. Enter the full path to the main certificate.key
   12. Enter the full path to the root CA root.cer

It can take a while, because all the services will be stopped and started, but in the end you will have your vCenter with HTTPS connection with the DNS name(s) you choose.
 
 
I had one error with my certificate:
Command Output: /root/cert/certificate.cer: OK
Status : 10% Completed [Replacing Machine SSL Cert…]
Previous MACHINE_SSL_CERT Subject Alternative Name does not match new MACHINE_SSL_CERTIFICATE Subject Alternative Name
Performing rollback of Machine SSL Cert…
Get site nameus : 0% Completed [Rollback Machine SSL Cert…]

 

For me that was not obvious, because my SAN was correct. So I investigated further and found that the new certificate had this Subject Alternative Names:
  • hostname.domain.com
  • cname.domain.com

But vCenter was expecting the following SANs:

  • hostname(s)
  • ipv6address

So, the simple solution is to create another certificate with IPv6 SANs (not for me, because it was a external certificate) or just disable the SAN check in the Python Script!


     1. Edit with vi the file: /usr/lib/vmware-vmca/bin/certificate-manager
     2. Comment line 594 and line 595 (see below)

#        if var.strip() in ['1']:
#            iscomparerequired = compare_certificate_san
or
#        if var.strip() in ['1']:
#            iscomparerequired = compare_certificate_san_to_pnid(cert_file)

    3. Re-run the certificate manager
    4. Check if everything is ok.

0 0 votes
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x