twincitiesguy
commented
5 years ago The problem here is that the Config - ECS Bucket option always uses the smart-client, which will discover the node IPs automatically. We will add an option to turn that off, so you can provide a DNS name (preferably of a load balancer).
We have a company policy not to include IP addresses in the certificates signed by our corporate CA and the ECS has been configured with all 4 subnets (public, management, data and replication) and were using an LTM with SSL pass-through, thus the SSL/TLS certificate has multiple subject alternate names for the DNS names that include specific names for the LTM for S3, Swift and NFS as well as each nodes' DNS name for the data vlan/subnet.
The ecs-sync host does have the company CA included in the openssl and java certificate/key stores.
We're intending to primarily use ecs-sync for CAS data migration from Centera.
I picked up the issue when attempting to configure ecs-sync using the web ui to store and retrieve it's configuration on an ECS S3 bucket, and the process failed when using the HTTPS setting and port 9021 for the specified ECS hosts, but worked when using HTTP and port 9020.
From the ecs-sync-ui.log it seems as if the code uses the IP address of the supplied ECS nodes' DNS names and expects this to match the certificate common name - I don't know enough about the way the Java library checks the SSL certificates to know if this would succeed if the IP address was in the subject alternate names list on the certificate.
The expected behavior would be for ecs-sync-ui (and ecs-sync?) to not expect the IP address in the certificate but to use the supplied DNS hostnames and verify the certificate accordingly.
This is the behavior that pretty much all other S3 clients and web browsers have - using the DNS name when supplied/used in the connection and not only the IP address to verify the SSL certificate sent from the ECS nodes.
Logs: ecs-sync-ui.log ui-config.xml: ui-config.xml.txt