Select to view content in your preferred language

Can't build HA portal using cloudformation with private CA SSL certificate

1285
7
Jump to solution
01-24-2022 10:14 AM
Labels (1)
TimHaverlandNOAA
New Contributor III

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

 

 

0 Kudos
1 Solution

Accepted Solutions
ChristopherPawlyszyn
Esri Contributor

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!


-- Chris Pawlyszyn

View solution in original post

0 Kudos
7 Replies
ChristopherPawlyszyn
Esri Contributor

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!


-- Chris Pawlyszyn
0 Kudos
TimHaverlandNOAA
New Contributor III

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.

0 Kudos
ChristopherPawlyszyn
Esri Contributor

I published a zipped file geodatabase, but the publishing process should be analogous for a hosted feature layer through the Portal Home application.


-- Chris Pawlyszyn
0 Kudos
TimHaverlandNOAA
New Contributor III

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.

0 Kudos
ChristopherPawlyszyn
Esri Contributor

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.


-- Chris Pawlyszyn
0 Kudos
TimHaverlandNOAA
New Contributor III
Eureka! It turns out that my private-CA-issued certificate had a blank or null name in the SAN list, so it looks like that was causing server and/or portal TLS connections to halt or break. 
 
As soon as I removed that blank SAN name from my certificate and re-imported my certificate into AWS Certificate manager, the portal operated as expected. 
 
And as you said, importing the root certificate into the portal and server machines via the /server/admin and /portal/portaladmin machine interfaces was important. Without it I was getting some errors in thumbnail generation when I saved a web map (Export Web Map task). 
 
I should mention for others that the domain name I used for my deployment was defined in an AWS Route53 private hosted zone. 
 
Thanks for helping me work through this.
ChristopherPawlyszyn
Esri Contributor

Glad to hear! Thanks for following up with the fix details as well.


-- Chris Pawlyszyn
0 Kudos