Hi all,
Has anyone been successful in running the HA portal cloudformation template using an SSL certificate issued by your own private certificate authority?
We're trying to build an highly-available portal with this cloudformation template:
https://enterprise.arcgis.com/en/server/latest/cloud/amazon/cf-enterprise-ha.htm
After much banging around and working with esri tech support I can only get a fully functioning portal if my SSL certificate comes from a well-known certificate authority (Let's Encrypt for example).
I can actually get the HA portal stack to build using my privately-issued certificate, but the resulting portal can't publish feature services (I get the error ERROR 001506: Failed to download the data for the portal item). It appears that calls from server or portal through my load balancer are being rejected; I'm guessing because the server/portal components don't trust my privately-issued SSL certificate on my load balancer. I've tried loading my root certificate into the machines via the /server/admin and /portal/portaladmin interfaces but it doesn't seem to make a difference.
Thanks for your experiences, and ideas!
Tim
Solved! Go to Solution.
I gave this a shot just now and was able to use an SSL certificate signed by our internal certifying authority, so wanted to pass along a few thoughts that may (or may not) be applicable in your situation.
First, you'll want to make sure the certificate has a subject alternative name matching the DNS alias you specify in the deployment steps (not just a wildcard entry). Second, you'll want to make sure the DNS resolves to your ALB CNAME record prior to kicking-off the deployment. Third, you'll need to import the root CA and any intermediate CA certificates (public keys) into Portal's PortalAdmin and Server's Admin endpoints for both machines. The third step will have to be done following the completion of the deployment, and you'll want to make sure to allow both Portal machines to restart following the certificate import.
Hope that helps!
I gave this a shot just now and was able to use an SSL certificate signed by our internal certifying authority, so wanted to pass along a few thoughts that may (or may not) be applicable in your situation.
First, you'll want to make sure the certificate has a subject alternative name matching the DNS alias you specify in the deployment steps (not just a wildcard entry). Second, you'll want to make sure the DNS resolves to your ALB CNAME record prior to kicking-off the deployment. Third, you'll need to import the root CA and any intermediate CA certificates (public keys) into Portal's PortalAdmin and Server's Admin endpoints for both machines. The third step will have to be done following the completion of the deployment, and you'll want to make sure to allow both Portal machines to restart following the certificate import.
Hope that helps!
Thanks, this is encouraging! Were you able to publish a zipped shapefile as a feature service? That's the problem I'm having when I use a private CA cert.
I published a zipped file geodatabase, but the publishing process should be analogous for a hosted feature layer through the Portal Home application.
Thanks Christopher. Some additional questions: was the domain name for your deployment publicly resolvable? Is your load balancer using an internet-facing or internal scheme? My load balancer is using the internal scheme. I have both a publicly-resolvable domain name (via Route53 public hosted zone) and VPC-only domain name (via Route53 private hosted zone) so I will test both.
My deployment was internet-facing with a public DNS record, but as long as the DNS resolves from the client machines that are running the orchestration pieces I think either would be fine. If the clients weren't able to resolve the DNS alias, the federation step would fail long before the deployment completed successfully.
Glad to hear! Thanks for following up with the fix details as well.