6.5.21 Ivanti Connect Secure

Allow REST API access for the admin account and choose which ports get the new certificate

The Ivanti Connect Secure (Pulse Secure): VPN Device Certificate template imports the certificate, assigns it to the specified ports, and deletes the previous certificate if no port still uses it.

New VPN connections use the new certificate right away. Users who are already connected stay connected.

Requirements

  • Ivanti Connect Secure 9.1R14 or later. 22.x is recommended. CertKit doesn’t check the version, so confirm it yourself.
  • The agent’s computer must reach the gateway’s admin interface over HTTPS. If that isn’t on port 443, add the port to Connect Secure hostname/IP and optional port, for example 10.1.2.3:8443. A self-signed admin certificate is fine.
  • In a cluster, point the template at the node you manage. The change copies to the other nodes.

Set up the admin account

The template authenticates to the REST API with Administrator username and Administrator password. Configure the account in the admin console:

  1. Under Authentication > Auth. Server > Administrators > Users, open the account and turn on Allow access to REST APIs.
  2. Under Administrators > Admin Realms, check the account’s realm. Set Administrator realm to match it. The default is Admin Users; change it in Advanced view if needed.
  3. Give the account an admin role that can change System > Configuration > Certificates. The built-in .Administrators role works.

The API account must support username/password authentication without MFA or a client certificate.

Ports

Ports to assign is a comma-separated list of ports that should use the new certificate. The default, <External Port>, is the port VPN users connect to. You can add <Internal Port>, <Management Port>, or virtual port names. Virtual port names must match the gateway exactly.

Ports you don’t list keep their current certificate. The old certificate is only deleted when no port uses it anymore. For example, if it served both the external and internal ports, list both or it stays.

If the gateway rejects a port change, CertKit puts the ports back the way they were.

Intermediate certificates

CertKit imports the certificate with its intermediate chain. It doesn’t manage the separate Intermediate Device CAs list under System > Configuration > Certificates > Device Certificates. If clients report an incomplete chain after deployment, check that the required intermediate CA is in that list.

Common problems

  • “Realm authentication failed”: check that Allow access to REST APIs is on for the account, the password is right, and Administrator realm matches the account’s admin realm exactly, including capitals and spaces.
  • “Realm authentication did not return an api_key”: the gateway answered but didn’t allow API access. Check REST API access on the account, and that the realm doesn’t ask for a second sign-in step.
  • “Certificate import failed”: check that the account’s admin role can change device certificates and that the gateway runs 9.1R14 or later. The error includes the gateway’s own message.
  • “Expected exactly one certificate with a private key”: the file isn’t the PFX CertKit made for this certificate. Keep the certificate format the template selects and deploy again.
  • “After the update the certificate does not list port(s)”: a virtual port name doesn’t match the gateway, or you listed <Management Port> on an appliance without a management port.
  • Old certificate not deleted: it still serves a port that isn’t in Ports to assign. Add that port, or delete the certificate by hand.
  • Admin console still shows the old certificate: the admin console uses the certificate on the port you browse to. Add <Internal Port> or <Management Port> to Ports to assign if it should use the new one.