installing identity manager FQDN

[josefdi]

Hi

I am getting the error " Invalid Identity Manager url, unable to find valid certificate to " when it ry to install the load balanced FQDN URL..

I had installed the root CA certificate...but When i try to connect using curl, get the below response..any pointers please

error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

* About to connect() to  port 443 (#0)

*   Trying .. connected

* Connected to port 443 (#0)

* successfully set certificate verify locations:

*   CAfile: none

  CApath: /etc/ssl/certs/

* SSLv3, TLS handshake, Client hello (1):

* SSLv3, TLS alert, Server hello (2):

* error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

* Closing connection #0

[pbjork · Accepted solution]

‌Have you looken at this blog post? Workspace Portal - Trouble Changing the FQDN - Horizon Tech Blog - VMware Blogs

[josefdi]

Thanks .. I have gone through the link..

am able to ping, DNS entries are corrrect , able to forward and reverse lookup the fqdn and IP..Able to connect to the FQDN

but getting the SSL timeout..as shown below when i runt the curl command

curl -v -3 -ssl https://my.fqdn.com

* About to connect() to https:// myfqdn.com port 443 (#0)

*   Trying 10..X.X.X connected

* Connected to XXXXXXXX) port 443 (#0)

* successfully set certificate verify locations:

*   CAfile: none

  CApath: /etc/ssl/certs/

* SSLv3, TLS handshake, Client hello (1):

* SSL connection timeout

* Closing connection #0

[Squidly_Man]

Check the following:

• DNS - Each Identity Manager appliance has a Forward (A) record and a Reverse (PTR) record.
• Reverse Proxy / VIP FQDN - Reverse Proxy or Virtual IP is Online and addressable both with a Forward (A) record and a Reverse (PTR) record.
  • If you are using a load balancer/reverse proxy like F5 BIG-IP, be sure the virtual server health monitor reports the Pool as green.  See F5 BIG-IP docs on configuration​ inside blog post).
• Certificates - All certificates should have full chains - not just the child certs.
  • Certificates which the Reverse Proxy uses for backend communication has complete certificate chain available to it for VMware Identity Manager appliances Subject Alternate Names for internal FQDNs if using specific certs (recommended).
  • Identity Manager is using the Root CA which the Reverse Proxy or Load Balancer is using (not the full cert chain - just the root CA cert).  This means including any and all intermediate certs in the proper order.
  • Ensure the certificate chains are in the proper order.  When pasting the OpenSSL PEM formatted certificate chain into VMware Identity Manager, the order is shown below.  This is assuming a child cert, two intermediate certs, and the CA certificate.  If there is only one intermediate, then obviously one cert would be removed.  If there are load balanced intermediate certs, then both may need to be applied (both will need to be loaded on an F5 BIG-IP Load Balancer for proper cert termination).
    
    -----BEGIN CERTIFICATE-----
    ...your child certificate goes here...
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    ...your first intermediate certificate goes here...
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    ...your second intermediate certificate goes here...
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    ...your root CA certificate...
    -----END CERTIFICATE-----
    
    
    For more on certificates, see the online VMware Identity Manager documentation.
    
    
• Firewalls - Routing 443 and other necessary ports (depending upon solution) between all subnets is open.
  • Make sure each appliance can resolve and reach (ping) the FQDN IP.
  • If you don't enable ICMP, then use `curl` commands to pull a web address via the console.  With the below, you should get a 'true' or 'false' depending on the status being returned.  The thing you are looking for is not the status - but that you actually get a response.  Whether it is true or false is irrelevant at this stage.
    
    

    curl 'https://<fqdn_of_another_appliance_in_the_cluster>/SAAS/API/1.0/REST/system/health/allOk'
    
    

    • Test both the FQDNs of the appliances within the cluster as well as the cluster FQDN.  If you do not get a true or false on the above test, you'll need to narrow down why the appliance cannot resolve / connect to another appliance or the cluster FQDN.
  • This partially goes to DNS again, but do an NSLOOKUP on both the names of the other appliances and the VIP(s) or cluster FQDN(s).

This should be a good start.  If anything doesn't work, chase it down and figure out why.  🙂