<!-- Verify first that your issue/request is not already reported on GitHub. Also test if the latest release and master branch are affected too. Always add information AFTER of these HTML comments, but no need to delete the comments. -->
##### ISSUE TYPE <!-- Pick one below and delete the rest --> * Bug Report ##### COMPONENT NAME <!-- Categorize the issue, e.g. API, VR, VPN, UI, etc. --> ~~~ CA ~~~ ##### CLOUDSTACK VERSION <!-- New line separated list of affected versions, commit ID for issues on master branch. --> ~~~ 4.11.1.0 ~~~ ##### CONFIGURATION <!-- Information about the configuration if relevant, e.g. basic network, advanced networking, etc. N/A otherwise --> Two management servers using a VIP and UCARP for failover. ##### OS / ENVIRONMENT <!-- Information about the environment if relevant, N/A otherwise --> N/A ##### SUMMARY <!-- Explain the problem/feature briefly --> Secure connections between two management servers using the default root CA provider don't pass validation if the default interface has multiple IP addresses. For example, using a Virtual IP with UCARP for management server failover, the default interface on the primary management server will have two IP addresses assigned. The Cloudstack RootCAProvider generates certificates by using one IP address from the default interface and including it in the certificate as a SAN (from my experience, the Virtual IP is put in the certificate). When the primary management server attempts connection to the secondary management server, the connection is rejected because the secondary server determines the connection to be from the 'real' IP address of the primary server and cannot validate the certificate because only the Virtual IP is listed as a SAN. ##### STEPS TO REPRODUCE <!-- For bugs, show exactly how to reproduce the problem, using a minimal test-case. Use Screenshots if accurate. For new features, show how the feature would be used. --> <!-- Paste example playbooks or commands between quotes below --> ~~~ Example: Let's say we have the following: primary server's IP is 192.168.1.10 and Virtual IP is 192.168.1.20 The certificate is generated with 192.168.1.20 as a SAN. The secondary server attempts to validate a connection from the primary. The connection is from 192.168.1.10, so it can't validate the certificate presented by the primary controller. In the logs you can find the following: Certificate ownership verification failed for client: 192.168.1.10 A client/agent attempting connection from address=192.168.1.10 has presented these certificate(s): Certificate [1] : Serial: xxx Not Before:Wed Oct 03 04:29:46 UTC 2018 Not After:Fri Sep 25 16:29:46 UTC 2048 Signature Algorithm:SHA256withRSA Version:3 Subject DN:CN=cloudstack1.example.com Issuer DN:CN=ca.cloudstack.apache.org Alternative Names:[[7, 192.168.1.20], [2, cloudstack1.example.com]] Certificate [2] : Serial: xxx Not Before:Mon Aug 20 05:27:08 UTC 2018 Not After:Wed Aug 12 17:27:08 UTC 2048 Signature Algorithm:SHA256withRSA Version:3 Subject DN:CN=ca.cloudstack.apache.org Issuer DN:CN=ca.cloudstack.apache.org Alternative Names:null ~~~ <!-- You can also paste gist.github.com links for larger files --> ##### EXPECTED RESULTS <!-- What did you expect to happen when running the steps above? --> ~~~ I would expect all IP addresses for the default interface to be included as Subject Alternative Names in the certificate. ~~~ ##### ACTUAL RESULTS <!-- What actually happened? --> <!-- Paste verbatim command output between quotes below --> ~~~ Only the Virtual IP is included in the certificate as a Subject Alternative Name on the primary controller and connection to the secondary controller fails validation. ~~~ [ Full content available at: https://github.com/apache/cloudstack/issues/2877 ] This message was relayed via gitbox.apache.org for devnull@infra.apache.org
