SSL Certificates#
The Identity and Access Management team owns the preferred process to request SSL Certificates. Find the link to the WebForm to request a self-service account and a Management Overview guide for DRAOs on the it.umn.edu SSL Certificate Guide page.
Basic considerations#
- InCommon is the preferred SSL Certificate management solution for University systems
- This method requires “DCV” - domain control validation. If you do not control the domain you will be requesting certificates for, you need to work with whoever does to establish a process for certificate management.
- New customers can request SSL Certificate management access
- Let’sEncrypt is used in situations where the InCommon certificate management process doesn’t work, for instance, if you don't control the network domain that you are requesting the cert for
- Let’sEncrypt is the default CA for Certbot, but you can adjust it to use InCommon
- DevEx has created some ansible code to use InCommon CA for Certbot with Apache
- This technology has not been reviewed by SARB -- use at your own risk
- Let’sEncrypt is the default CA for Certbot, but you can adjust it to use InCommon
Private IP addresses#
Certificates for hostnames in networks controlled by OIT likely need Hosting to assist with any self-service using InCommon.
SSL termination using F5#
- For web apps and pages hosted on servers in private-network space, a virtual IP (VIP) can help act as a public endpoint
- Managing certificates at the F5 requires an account on the F5 with a Certificate Manager role, but can be done manually by the NTS team by opening a Network Load Balancer (F5) Request
- Also gives you the ability to see client IP addresses in your web server logs, via the X-Forwarded-For header
- Managing certificates at the F5 requires an account on the F5 with a Certificate Manager role, but can be done manually by the NTS team by opening a Network Load Balancer (F5) Request