Skip to main content
University of Florida
NaviGator AI home page NaviGator AI

SSL Certificates

This InCommon SSL certification program began in Spring, 2011. Using this program, any University of Florida domain may obtain SSL certificates at no cost to the host department. A license agreement funded by the University of Florida Information Technology provides an unlimited number of certificates for the University of Florida through a contract with the InCommon Federation. Starting July 17, 2026, the SSL certificates are issued from CERTInext, via the InCommon agreement.

Each college and major unit director may assign two or three individuals within their area to administer the SSL certificates.

Assistance

For assistance, please open a Certificate Management service ticket or for general questions please contact the UFIT Identity & Access Management team.

Decreasing Certificate and Domain Validation lifespans


UF certificate admins and certificate users need to be aware of the industry-wide shortening of public-CA-issued certificate lifespans that is occurring over the next few years.

TLS maximum certificate lifespans:

  • Current (mid-2026) lifespan: 6 months (200 days)
  • Beginning 2027: 3 months (100 days)
  • Beginning 2029: 1 month (47 days)

If you are responsible for DCV for any domains (most domains besides *.ufl.edu), please be aware of the diminishing DCV lifespans.

Domain Control Validation (DCV) lifespans:

  • Current lifespan: 6 months (200 days)
  • Beginning 2027: 3 months (100 days)
  • Beginning 2029: 10 days.

Request a Certificate

UFIT IAM doesn't directly provide SSL Certificates.  Instead, we delegate that ability to College and Departmental IT groups around the University.  So you will work with your local IT to acquire a certification.  The following 3 steps outline how to go about acquiring a certification. Please contact the Certificate Administrators if you have any questions.

To obtain SSL certificates, staff should contact the IT office for their respective college or unit. Each college and unit should have established localized procedures. If there are issues finding a contact, the UFIT Identity & Access Management team can assist you in locating the appropriate staff member for your college or unit. In most cases, certificates may be obtained within a few hours.

For information about how a college or other unit can become enabled to issue InCommon certificates, plese see the information on setting up/changing departmental administrator access below.

Setting Up or Changing Departmental Administrator Access

The process for a unit to become enabled to issue InCommon SSL certificates is easy.  The college or unit IT director provides:

  • information regarding the college
  • the domains within that unit, and
  • the names of two or three individuals who should be given access to the CERTInext software tools. These individuals will serve as the Departmental Administrators in the CERTInext platform.

Follow the instructions below to get a certificate.

The first step for a unit to become enabled to manage and request certificates is to create a group name. This will create a college group per Campus IT director. An example of the data required includes:

  • College Name: Engineering, College of

The Certificate Administrator reserves the right to alter the submitted college descriptive name. Name that are easily found in an alphabetic list are preferred. For example, College of Engineering may be entered as Engineering, College of.

Provide a list of domains you want to activate SSL certificates for in your unit. You can send as many as you like. At least one domain is required for initial setup. You may add others as you need to by submitting them to UFIT IAM with a Certificate Management ticket. The preferred style of your submitted list of domains is like this: Domain: *.eng.ufl.edu, Description: College of Engineering website Domain: *.ise.ufl.edu, Description: Industrial Engineering website

The IT director should submit information for two or three individuals to be setup for their area. As a reminder, these individuals will be known as a UF Dept. Admins in the CERTInext platform. The information required for each individual should be submitted like this:

  • GatorLink ID: algator
  • Full Name of the proposed Dept Admin: Alligator, Albert T.
  • Phone number: 555-1383

Note: Due to limitations with CERTInext's SSO, in order to function the admin must have their gatorlink@ufl.edu address as a deliverable email address.  This will be true of anyone with an active mailbox in the UF Gatormail email system.

After an individual is added for the unit, they will receive an email from CERTInext to activate their new account in the system.

Support

Support for the InCommon Certificate service can be acquired via a few channels, depending on what assistance you need.

If you need assistance with any of the following, please submit a Certificate Management ticket to UFIT IAM to: 

  • Add a new domain
  • Add a department
  • Add/Remove departmental administrators
  • Change permissions for a department or dept. administrator 

Additional information such as user guides and technical support can be found at InCommon's certificate support website.

If you encounter a technical problem with the CERTInext system, please consult their support information, and/or open a ticket with CERTInext directly:

For more information about InCommon Certificate services, including technical information:

Technical How-tos

This section is intended to provide technical information to approved Departmental Administrators with access to the CERTInext platform.


Accessing CERTInext

Only approved Departmental Administrators can log in to the CERTInext platform.

Login page: https://us.certinext.io/

Use SSO to login:

  1. either the "Single Sign-On (SSO)" link - you will need to enter your gatorlink@ufl.edu in the pop-up
  2. or use the "From an InCommon member institution?" link which will take you through a federated login flow.

Please make use of UF SSO rather than using your local password as SSO will be required in the near future.


Certificate creation and management

There are 2 main ways to create certificates: via the platform's UI (https://us.certinext.io) or via the certinext APIs.

Using the UI is fine at a small-scale for now, as certificate lifecycles are still at 6 months.  However, in Jan. 2027 certificate lifecycles will decrease to 3 months, and then in early 2029 life-span will decrease to 1 month.  With this in mind, moving towards automated management is critical for certificate management going forward.

 

Using the UI

  1. log in to https://us.certinext.io
  2. click the 'New Certificate' button in the top-left menu
  3. Choose Product & Validity:
    1. If you are in multiple Groups, select the Group that will own this cert.  The group you select will affect which domains you can issue certs for
    2. CA Source: choose emSign
    3. Certificate Type: SSL/TLS Certificates
    4. Product: You probably want:
      1. "InCommon OV SSL Certificate" for a single domain cert
      2. "InCommon OV SSL Certificate UCC" for a multi-domain cert
      3. "InCommon OV SSL Certitifate Wildcard" for a wildcard cert
    5. Subscription For: 1/2/3 years
      1. max validity is still 6 months (90 days beginning 2027), this option doesn't effect validity
      2. use the "mouse-over" of the (i) on this one for a description of how it might help you with auto-renewal
      3. note the mouse-over text will state that all certs are limited to 90-days, InCommon got an exception to this until end of 2026.
  4. Next you will upload or paste your CSR
  5. Select an Organization to issue your OV Cert for: this UI isn't obvious, but you should click on the University of Florida (4266464), which will pre-fill the Org name and Address.  DO NOT manually enter a new address in the various fields - this will block your OV cert from being issued.
  6. For Org Representative Infomation: leave the pre-populated admin as your representative - fill in the Certificate Download Delegation with the name/email address who should receive the email with download links to fetch the certificate.
  7. Review the order.  By default your cert will also contain the www variant of your name, you can uncheck this.  I suggest leaving the Domain Name matching whatever your CSR included to prevent delay in cert issuance.

 

Using ACME

ACME is a standard protocol and there are many ACME clients available across platforms.  You will need to research which client works best for you.   

Clients known to work well with CERTInext are: certbot, win-acme, acme.sh

As an overview, here's the workflow to generate a new ACME-EAB credential and begin using ACME:

  1. In the CertiNext platform UI, Navigate to Integrations > APIs
    1. you can view existing API credentials associated with your group (including viewing their Key ID and Mac Key)
    2. or create a new credential
  2. Create a new ACME credential:
    1. click the "+Create API Credentials" link in the top right of the page
    2. Select:
      1. API Type: ACME
      2. CA Connector: emSign
      3. Identifier: 
        1. here you'll want to pick an identifier that makes sense to you and your team.  I will ask that you also include your dept name as the first "token" in the name, e.g. "mydept-wordpress-ucc-acme"
          1. why ucc? See the "product" section below - ACME credentials are tied to a specific product (cert profile).  So when you create your ACME credential you should label it with the type of certs it can issue- the example would be for an ACME credential that can issue UCC (multi-domain) certs.
      4. User:
        1. Here you will need to pick a user from your group to assign the ACME token to.  I would recommend picking yourself.
      5.   Groups:
        1. Select the group that this credential will be associated with.  Most people will be in only a single group, but if you are in multiple groups you will have a choice to make.  Since domain delegation happens at the Group level, be sure the ACME credential is associated with the group who manages the domains you will be issuing certs for with this credential.
      6. Product: You probably want:

        1. "InCommon OV SSL Certificate" for a single domain cert

        2. "InCommon OV SSL Certificate UCC" for a multi-domain cert
        3. "InCommon OV SSL Certitifate Wildcard" for a wildcard cert
      7. Organization:
        1. Your Group membership will inform which organization you can issue certs against - most groups will be limited to "University of Florida(4266464)", which is UF's default org in CertiNext and can be used for issuing OV certs.
  3. Use your favorite ACME client to register with the newly generated ACME-EAB credential
  4. Begin issuing and managing certs with your favorite ACME client.

 

ACME-EAB accounts and pre-validated domains in CertiNext

The expected pattern for ACME cert management is for you to create and make use of an ACME API credential, and then issue certificates within a pre-validated domain - meaning you do not have to perform DCV for each ACME request.  This is essentially the same pattern we used with Sectigo Cert Manager (for those familiar with using ACME in the old InCommon system).

 

Adding a new non-ufl.edu domain

Some departments may need to support domains that don't fall under ufl.edu.  In these cases, here is the recommended procedure:

 

  • Open a ticket with UFIT IAM requesting the new domain be delegated to your CERTInext group
    • IAM will review the request and if appropriate, add the domain to your group's abilities - to help with this please provide a brief description of the domain's use - how is this domain related to UF business?
  • Add the domain as a new domain in the CERTInext web UI:
    • Certificates > Orders > Domains (tab) > + Create Domain (button)
    • When adding the domain to the tenant be sure to select the "University of Florida (4266464)" as the organization
  • Perform DCV to validate the domain*
    • once the apex domain (e.g. example.com) is validated, subsequent requests for subdomains (e.g. host.example.com) should inherit the parent domain's pre-validated status
    • DCV inheritance only works with performing DNS-based DCV.  Inheritance will not work if you use HTTP-based DCV
  •  Begin issuing certificates within the domain

 

* DCV lifespans are currently 6 months, but are heading towards 10 days in 2029, so automating DCV with CERTInext's REST API is recommended.

 

ACME examples

Three common acme clients that I've seen mentioned as working with CERTInext are:

acme.sh

After creating ACME API credentials (ACME-EAB) in the CERTInext UI, those creds can be used to register and issue certificates for domains that are delegated to the Group that the API credential is assigned.

Examples:

Registration

Before being able to issue certs with acme.sh, you have to register the client using the API credentials you created in the UI:

./acme.sh --register-account --server https://acme-us.certinext.io/v1/directory --eab-kid API_CRED_KEY_ID --eab-hmac-key API_MAC_KEY

Where API_CRED_KEY_ID is the "Key ID" value and API_MAC_KEY is "Mac Key" value from the CERTInext ACME credential you have created. 

Issue Cert

After registration, you can issue certs with the registered API cred:

./acme.sh --issue --server https://acme-us.certinext.io/v1/directory -d host.dept.ufl.edu --keylength 2048 --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please

The above incantation is to issue a cert for "host.dept.ufl.edu"- of course your group would need to be delegated access to the dept.ufl.edu domain.  The --dns --yes-I-know... flaggs are to tell the acme.sh to not worry about trying to handle live DNS DCV as we're primarily using pre-validated domains (ufl.edu) with DCV inheritance.