/
FORUM: cert-user Notes

FORUM: cert-user Notes

FROM Sara Jeanes, Director, certificate service, Internet2/InCommon

  • Tickets can be submitted here: https://incommonsupport.certinext.io/portal/en/home or emailed to support@certinext.io 

  • The Wiki has gotten another refresh and is now easier to navigate. The Wiki is here: https://spaces.at.internet2.edu/x/vAAlFw

  • There is a new button on the CertiNext home page to Login with InCommon.

  • Public Client Authentication, S/MIME, and EV Code Signing Add-ons are still on track to be available for ordering in mid to late May.

Additional documentation is now available.

  • The CertiNext platform supports a whole host of integration options and the team is in active development on additional ones from feedback in the Workshops. The current list of integrations available to InCommon Certificate Service subscribers are:

    • Load balancers, network & WAF 

      • F5, Palo Alto, FortiGate, Akamai, Cloudflare 

    • Cloud & orchestration 

      • AWS (including AWS Certificate Manager), Kubernetes, Azure KeyVault

    • 3rd-Party Certificate Lifecycle Managers

      • ServiceNow (basic, additional functionality coming very soon), MyID, Microsoft Active Directory Certificate Services (ADCS)

    • DNS integrations for Domain Control Validation (DCV)

      • AWS Route 53, Azure DNS, Cloudflare

  • We have updated documentation on getting your CertiNext accounts connected to the InCommon Federation (Thanks Nadim!). That documentation can be found here: https://spaces.at.internet2.edu/x/PoC9Fw 

 

 

 

 

From Paul Caskey

  • The February 2nd date was just 200 days after the July 17th date, the date our service with Sectigo will end.  It’s the date when we expected all certificates issued prior to the Sectigo service ending will have naturally expired, though someone pointed out yesterday that getting a 398-day cert prior to the cutdown to 200 day certs would extend the natural validity date past Feb 2nd.  We’re just trying to say that active certs should continue to work just fine for their natural lifetime.

  • Sectigo ACME will stop working on July 17th and Certinext ACME will start working once you have signed the new agreement.

 

Valid Concerns about certificate validity:

  • Issued certificates will still be valid.

  • Certificate validity is a cryptographic function based on trust from the issuing certs above them. It's not tied to us having a relationship with Sectigo via Incommon.

  • We will most likely lose access to SCM in February, which will remove your ability to revoke those valid certs if there is a reason to do so.

  • It's not 100% needed, but would be a good security posture to renew them once you have access to the new platform.

 

CertiCAT?

  • If you're currently using Sectigo ACME, I highly recommend switching to something like https://github.com/RIT-ITS/CertifiCat

  • Using CertifiCat means any changes to CA issuance can be made in one place instead of having to update every client.

  • My recommendation would be to setup CertifiCat this week against Sectigo and start moving your ACME clients to using it.  Once you're setup with Certinext and Clay has updated CertifiCat with Certinext integration, you should be able to update CertifiCat and all your ACME clients will just keep working.  This will give you a longer window to migrate all your ACME clients.

 

Sara Jeanes - Internet2/InCommon

 

 

 

 

I have explored pretty all I can explore in the Sandbox.  I have successfully written code that interfaces with both the REST API account and ACME account under the “ET” group.   All the code works, except it is failing because within the Sandbox environment, there are no approved domains or organizations that pass the DCV validation, so nothing will issue.   I am confident that once my request for a certificate for a domain that is “Organizationally Validated” (OV) it will issue, and the same for any vanity domain that has been DCV domain validated (DV).

certinext_org_hierarchy.png

CERTInext has removed some of the granularity of RBAC that we had become accustomed to in the Sectigo platform.   It looks like we are very limited in the ability to hand out granular control like we used to be able to do in Sectigo.

See “reseller model” that we do not have under our enterprise account, where it looks like we gain a little more granularity, but as of now we do not have this, and not sure if can get the “reseller model”.

There are realistically two options, and CERTInext gives no clean middle:

  • Option A — Administrator (Primary Admin) role. The only role that can create Groups and assign domains to them. If the goal is for me to be the self-service certificate-automation SME who can stand up groups for ET and other teams, this is the required level — but it's account-wide power that cannot be scoped to a subtree (CERTInext has no "admin of just my corner" short of the reseller model UT doesn't use).

  • Option B — Manager limited to specific groups (the "Group Admin"/DRAO equivalent). I can issue, approve, and create ACME/EAB creds within groups ISO creates for me, but I cannot create new groups or scope their domains — that stays an Administrator task.

In Sectigo my DRAO account let me create ACME accounts, attach domains, and hand creds to groups. In CERTInext, two of those (group creation, domain-to-group scoping) are Administrator-only, which is exactly what my current sandbox access blocks. I'd ask for Administrator in sandbox (so I can actually test the full workflow) and we decide A vs B for production based on how much you're willing to delegate.

The CERTInext pattern: department = Group; the Group carries the domain permit/restrict scope; EAB/ACME credentials are created under a Group (bound to User + Group + Product). Per scope:

  1. An Administrator creates the Group and sets its domain scope (Sectigo "assign domains to the ACME account" → CERTInext "scope domains on the Group").

  2. ACME/EAB credentials are then minted under that Group — and this step does not require Administrator (Manager, or even the team's own user, can do it).

  3. Hand the team their EAB Key ID + MAC + the account-specific directory URL (…/acme/<account-id>/directory).

The piece I currently can't do is step 1 (group creation + domain scoping), which is Administrator-only and unavailable at my permission level.

The WHOLE POINT of have the various ACME accounts was to control what domains/FQDNs they could issue certificates for — and it was working great!

This would need to be updated to basically “service accounts” that are created under a group, kinda how I had been doing it.

The difference between CERTInext and Sectigo, is that all accounts created under a group have all the same access to all the same domains/FQDNs.   The only granular difference between CERTInext accounts is “product”, where we could control things like no wildcards, or certs over a specific term length, or types of certificates (DV, RSA, OV, and EV) per “ACME or API account” within a group.

Right now - all the accounts below (being under the ET-Enterprise Technology GROUP), the ALL have access to create certificates for ALL the domains listed under the group.  I would have to delete all these accounts and convert these to GROUPS to mimic what we did in Sectigo. 

PastedGraphic-2.png

Under Sectigo - I was limited to DRAO under our account, but you all gave me the ability to create ACME accounts and assign domains to each one.   This is no longer possible in CERTInext, as stated above, only the role of “Administrator” can create groups (that hold domains/FQDNs) to limit what an ACME/API account can issue against that is created until a group.   All accounts under a group have the same access to the same domains/FQDNs.

HOWEVER, an admin account that I would use could be a “admin service account”, but you lose accountability to a specific person, since the account would be “generic”.   So I would not recommend that in the CERTInext platform.  

HERE IS THE CATCH:  

We want to take a much of these tasks off our plates, especially the certificate creation process.    Right now we have the following:

  • Help Desk

  • Quite a few DRAO accounts for individuals in a department.

  • ISO

In the CERTInext platform:

  • Help Desk staff would need to become managers for a group and the admins would need to ensure all the appropriate domains and FQDNs were added to their group, so they could use the dashboard or “certificate_tools” that would allow them to create certificates in responses to requests from their customers as incoming tickets.  The HELP DESK group would need to contain domains and FQDNs that spread across multiple groups as they help wide variety of people and departments.

  • DRAO account holders, once again, each DRAO would become a manager in their group.  Once again, the admins would need to ensure all the appropriate domains and FQDNs were added to their group, so they could use the dashboard or “certificate_tools” that would allow them to create certificates.

  • ISO and Admins - this would be your team, and hopefully you would include me, as stated previously, only admins can create groups for which domains/FQDNs are added to control who can issue certificates for those domains/FQDNs.