Hello,
The guiding entities of the Internet have embarked on a timeline to reduce TLS Certificate lifetimes from 398 to 47 days by March 2029. ESRI needs to be ready to embrace this with automated certificate management tools. Much like the ACME tools commonly discussed with Let's Encrypt certificate deployments. This will help unburden administration staff where possible.
https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days
Respectfully
Tom
Thank you for posting this. It is such a drastic change, and even though there are automated methods for cert renewal, installation, etc. the full process is certainly not there when it comes to specific applications and appliances, ESRI included. We'll have to see how all of this shakes out.
Thanks for sharing this, it's indeed a pretty significant change. An important recommendation here is a reminder that ArcGIS Enterprise administrators can simplify their lives substantially by only applying this guidance and automation to their reverse proxy or load balancer, all client traffic routed through that endpoint would then be able to benefit from automated certificate management, and likely the software + cloud providers will have good patterns for managing cert renewal on those endpoints by that time (and already do in many cases). Applying and re-applying CA-signed and trusted certs to backend endpoints that users do not interact with is comparatively not as critical, and that distinction between 6443 + 7443 + other endpoints is important.
Some users may have "end to end trust" requirements where they need every communication to be through a trusted, valid cert, but this is more uncommon in my experience.
@AndrewFarraragreed. Just trying to make sure all know change is coming. As you say with specific applications we are looking at the need to replace a few that have onerous certificate updates. Our SFTP server being one of them where the binding is made manually deep inside the application.
@SamLibbyYou bring up a very good point in that it is largely the external facing components that will need the management. Is the implication that the back end certs could operate under self-signed certs or something else? I thought the Enterprise Deployment class suggested self-signed could be used for testing but that valid certs should be used for production. Thanks for any clarification you can provide.
we are already here:
Zero Trust Maturity Model
Zero Trust: Understanding the US government’s requirements for enhanced cybersecurity
@ThomasHoman My recommendation is to use self-signed certificates for backend components (i.e. the 6443/7443 listeners of a GIS Server / Portal site) as they are not client-facing. If organizational or regulatory standards require those to be updated to CA-signed and valid certs, then that is a lot of additional management.
I do not know the content of the course you referred to, but I would say that my opinion is that statement is correct for the external-facing certs, not "all" certs. There are mostly opinions, not cut and dry facts here, unfortunately.
A few references:
Portal for ArcGIS 11.3 system requirements
https://enterprise.arcgis.com/en/system-requirements/11.3/windows/portal-for-arcgis-system-requirements.htm#ESRI_SECTION1_EE1B77F84DAD49FB90B174D7D1FF27C2
SSL certificates
Portal for ArcGIS is configured with a self-signed server certificate, which allows you to do initial testing of the portal and helps you quickly verify that your installation was successful. You must request a certificate from a trusted certificate authority (CA) and configure the portal to use it. The certificate can be signed by a corporate (internal) or commercial CA.
You must configure each applicable ArcGIS component in your organization with a certificate from a corporate or commercial CA. Common examples include ArcGIS Web Adaptor and ArcGIS Server. For example, ArcGIS Server includes a configured self-signed certificate. If you'll be federating the ArcGIS Server site with your portal, it's very important that you request a CA-signed certificate and configure the ArcGIS Server site and web adaptor to use it.
For more information, see Security best practices.
https://enterprise.arcgis.com/en/portal/11.3/administer/windows/security-best-practices.htm#ESRI_SECTION1_42767D241AA54256A1CC9255CCD6108E
"It's imperative that you use a CA-signed certificate to fully test and deploy your portal."
Yes please, renewing certs is annoying now, and will be such an important and regular workflow in the future that any help would be really important.
@BillFox ...and to cite the ArcGIS Enterprise Hardening Guide (p.54):"Basic: Implement Signed CA CertificatesInitial deployments of ArcGIS Enterprise edge components (Portal for ArcGIS and ArcGIS Server) areconfigured to use HTTPS through self-signed certificates generated at installation time. Self-signed certificates are sufficient for development and basic testing, but production deployments must use certificates signed by a certificate authority (CA)"
I find it frustrating to hear conflicting guidance regarding certs for core components from ESRI. I have an issue where my ArcGIS hosting Server will not register with ArcGIS Monitor, while all other Enterprise components set up in the exact same manner (OS, network-wise) have no issue. After exhausting all other troubleshooting we could think of, ESRI support suggested all Enterprise components must have CA-signed backend certs. Some of these cert updates can be automated via API or command line, but not all, and the methods are not consistent across the Enterprise components. We can use automated cert update solutions like LetsEncrypt and Certify the Web, but it seems like ESRI could make the steps of actually applying these certs a lot easier for Enterprise administrators.
self signed certificates may be fine during setup and initial upgrade, but a lot of enterprises block certain functions if a server is not able to verify the certificate chain to their CA. One example I saw recently was trying to dispatch mail through a proxy. (like mailgun or send grid)
Is there any additional guidance on this as we move towards the first phase of Certificate and Domain validation lifecycle reduction ?
No, still no official way to replace all certificates fully automated without writing custom code.
We would like an official reply on how to handle this. Especially since Portal for ArcGIS (11.3) doesn't support you to reload/refresh the certificate after updating through REST.
Yes, pleeeease.... The process to renew ArcGIS Enterprise certs is so cumbersome.
At the Dev Summit it was announced that with an upcoming release (12.1?), certificates can be renewed through the API without restart. We´ll have to see how it is implemented.
@SimonSchütte_ct Thanks for update.
Since Enterprise 11.3 is an extended release product with viability out to 2030, one would hope that they would honor such a critical functional need by taking up the task for all users and not just offer this for those on the front edge of the adoption curve.
While the no restart functionality would be helpful I would be more than happy with getting the certs in place under automation and having to restart on a planned schedule. We will be needing to do this every 45 days by 2030 anyway when the 47 day certs become mandatory in 2029.
Here's an example from Reddit r/ArcGIS for automating this process using an ACME (OP is using Certify the Web) and a PowerShell script to refresh certs through REST. I have not tested this yet...
https://www.reddit.com/r/ArcGIS/comments/1rl3lfu/arcgis_serverportaldatastore_ssl_automation/
@CortWilson Thanks for the link!
The code seems straight forward enough and a trailing service restart could be built in. For 11.x series of Enterprise solutions, I think this might be as close to an answer we can get to. I'm constrained for the moment at 11.3 due to vendor tool revisions.
- In 12.1 certificates can now be renewed through the API without restart
Connectez-vous pour publier, suivre du contenu, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.
