Important Considerations before upgrading Palo Alto Networks Trust Protection Foundation

Applies to

Upgrading to Trust Protection Foundation 26.2.

Summary

Trust Protection Foundation 26.2 introduces new functionality and several changes to existing functionality. Click here for a complete list of new 26.2 features for Trust Protection Foundation.

Palo Alto Networks Trust Protection Foundation is the new name for the suite of tools formerly known as Venafi Trust Protection Platform, and more recently as CyberArk Certificate Manager - Self-Hosted. Alongside its certificate management capabilities (formerly known as TLS Protect DataCenter), it includes SSH Manager for Machines (formerly known as SSH Protect) and Code Sign Manager (formerly known as CodeSign Protect).

IMPORTANT! Before upgrading, read through this article. Depending upon the version from which you’re upgrading, several enhancements made over the past two years to Trust Protection Foundation require that you take important steps, either before or immediately after upgrading. This section also includes comments regarding less critical but important changes to note as you upgrade.

Pay special attention to the list of features that have been deprecated, and to the list of features scheduled for deprecation.

For detailed information about this release, refer to the Readme online.

For detailed information on how to upgrade your installation to 26.1, please review the information in the Installation and Upgrade Guide.

Visit Product Life Cycle for more information about ship dates and when support for each version ends.

New in version 26.2

New Upgrade Readiness tool

Trust Protection Foundation 26.2 includes UpgradeReadiness.exe, a new tool that checks a server before you install or upgrade. It finds problems that cause upgrades to fail, like missing prerequisites, service account rights, database issues, and upgrades that didn’t finish. It replaces the PreFlight tool.

The tool is in the release .zip file, and you don’t need to install it. Run it as an administrator on each server. By default it only checks your server and doesn’t make changes. It can also fix some problems for you with the -fix-all or -fix-only option. Results are saved as HTML and JSON reports.

For more information, see Check a server before you install or upgrade (Upgrade Readiness).

Breaking Change: Installer and release package file names updated

As part of the rebrand of Venafi and CyberArk products into the Palo Alto Networks portfolio, the main installer and the release package have new file names in this release. If you use scripted installations or upgrades, or if your download automation matches on the package name, you need to update your scripts.

Note: XX.X.X represents the product version number.

No other MSI file names changed in this release. RemoteMmc-XX.X.X.msi, WinAdmin-XX.X.X.msi and UpdaterInstallerx64.msi keep the names they were given in 25.3.

Folder names, installation paths and component names remain unchanged, so you can continue to use existing Answer Files.

Breaking Change: Syslog over TLS validates the certificate against the configured host

Starting in 26.2, a syslog channel that uses TLS checks the syslog server’s certificate against the value in the channel’s Host setting exactly as you entered it, which is standard TLS behavior (RFC 5425). Earlier releases checked the certificate against the IP address that Host resolved to, so the certificate had to contain that IP address even when Host was a host name.

Action required: If Host is a host name and the server certificate carries only an iPAddress entry in its Subject Alternative Name (SAN) extension, the connection is refused after you upgrade and log messages stop reaching that server. Before upgrading, review each TLS-enabled syslog channel and reissue any certificate that needs it:

• If Host is a host name, the certificate must include that name as a dNSName entry in the SAN.
• If Host is an IP address, the certificate must include that address as an iPAddress entry in the SAN.
• A certificate that contains both the FQDN and the IP address works whether Host is set to the FQDN or to the IP address.

If the syslog server is behind a load balancer or proxy, the certificate it presents must include the name or IP address you entered in Host; the load balancer’s own IP address is not what the check uses.

These requirements apply when the platform’s Verification Mode is set to Basic or Strict. When it is set to None, Trust Protection Foundation accepts the server certificate without validating it against the names the certificate contains.

See About syslog channels.

Breaking Change: Composite certificates created before 26.2 are deleted on upgrade

Trust Protection Foundation 26.2 moves to version 19 of the composite certificate specification; the version 12 format used by earlier releases is out of date and no longer compatible. During the upgrade, a migration permanently deletes all composite certificate materials created before 26.2 — their private keys, CSRs, certificates, and vault IDs. There is no automatic conversion to the new format.

Action required: Before upgrading, inventory any composite certificates issued on a pre-26.2 release and export or back up anything you need to retain. After upgrading, re-issue those certificates under the 26.2 composite specification.

See Algorithm types supported by Trust Protection Foundation.

Breaking Change: SAML and OIDC connectors that rely on redirects, or have a + in the friendly name, stop working

Starting in 26.2, Trust Protection Foundation no longer supports redirects during SAML metadata loading at application start, or during OIDC backchannel validation. Your SAML and OIDC connectors must point directly at the Identity Provider’s endpoint rather than a URL that redirects to it.

Separately, if an SSO connector’s friendly name contains a + character and the connector is not configured for legacy SAML (that is, it does not use the /api/saml/acs URL), the integration stops working after upgrade.

Action required: Before upgrading, review each SAML and OIDC connector’s configured endpoints and confirm none of them rely on an HTTP redirect to reach the Identity Provider. Update any that do to point directly at the final endpoint.

After upgrading, for any SSO connector whose friendly name contains a + and that is not using legacy SAML, re-export the metadata from the Trust Protection Foundation Configuration Console, then copy the new Identity and Reply URL values into the Identity Provider’s SAML configuration.

If you run multiple Trust Protection Foundation servers behind a shared web server configuration, apply this change consistently across all nodes to avoid inconsistent SSO behavior during the upgrade window.

While your servers are on different versions, a SAML configuration change has to be made twice: once in the Configuration Console on a server still running 25.3 or earlier, and once in the Configuration Console on an upgraded server. If you update only one of them, SAML login works on that version and fails on the other.

SAML settings are migrated during installation only if SAML is enabled at the time you install the new version. If SAML is disabled when you upgrade, your previous settings are not carried over: you have to configure SAML again from the Configuration Console, on the identity connector of your choice, and then update the Identity Provider with the new Reply/ACS URL and Entity ID that the Configuration Console gives you.

See SAML Troubleshooting Tips.

Breaking Change: Stricter input validation on certificate request and renewal API calls

Starting in 26.2, the WebSDK enforces input validation on both certificate request creation (POST) and renewal detail updates (PUT) that was previously only partially enforced. Requests that previously succeeded despite containing invalid or malformed values are now rejected.

Action required: Before upgrading, review any automation or integrations that call the certificate request or renewal WebSDK endpoints directly and confirm the values they submit conform to expected formats. If your integration depends on previously-accepted non-conforming input, a targeted option to bypass the new validation is available — contact Support for details on enabling it for the specific affected interface.

Breaking change: Code Sign Manager WebSDK OrganizationalUnit is now a list

In 26.2, the OrganizationalUnit field on Certificate and Apple environments changed from an object to an array of strings, so an environment can have more than one OU.

Before 26.2:

"OrganizationalUnit": {
   "Info": 1,
   "TemplateValues": null,
   "Value": "Engineering"
}

26.2 and later:

"OrganizationalUnit": [ "Engineering", "QA" ]

The new format is used in the following WebSDK endpoints:

• POST Codesign/CreateEnvironment and POST Codesign/UpdateEnvironment, in both requests and responses
• POST Codesign/GetEnvironment and POST Codesign/FindEnvironment, in responses
• POST Codesign/GetProject and POST Codesign/EnumerateProjects, in each project’s CertificateEnvironments list

IMPORTANT: CreateEnvironment and UpdateEnvironment don’t return an error when a request uses the old object format. The call succeeds, but the OU is ignored. Unless OU is locked by the environment template or by policy, the environment is created or updated without an OU, and certificates issued for it won’t include one.

To avoid losing OU values:

• Update any scripts or integrations that create or update Certificate or Apple environments so that they send OrganizationalUnit as an array.
• Update any scripts that read OrganizationalUnit from an environment so that they expect an array. The environment’s OrganizationalUnit no longer includes Info or TemplateValues.

Scripts that read an environment on 26.2 and send it back unchanged already use the new format and aren’t affected.

Environment templates aren’t affected. A template’s OrganizationalUnit keeps its existing format.

Breaking Change: Code Sign Manager WebSDK legacy algorithm fields removed

Version 25.1 replaced the algorithm fields on Code Sign Manager environments and templates with PKIX parameter set fields, and deprecated the old fields. In 26.2, the old fields are removed: KeyAlgorithm, SigningKeyAlgorithm, EncryptionKeyAlgorithm and AuthenticationKeyAlgorithm. Values sent in them are ignored, and responses no longer include them. For the replacement fields on each environment and template type, see Codesign.

From 25.1 through 26.1, a value sent in a legacy field was converted to the matching PKIX parameter set. In 26.2, a request that sends a legacy field but no PKIX parameter set field has these results:

• POST Codesign/CreateEnvironment succeeds, and the environment gets the first algorithm in the template’s PKIX parameter set policy.
• POST Codesign/UpdateEnvironment fails with ValueProhibitedByTemplate. 26.2 now enforces the template’s PKIX parameter set policy, and it checks the values in the request body itself, so a request that leaves out the PKIX parameter set field fails. Leaving out any other value the template locks, such as the CA, subject, OU, key storage or expiration, fails the same way.
• POST Codesign/UpdateTemplate succeeds, but clears the template’s PKIX parameter set policy, so the template allows every algorithm for that environment type.

Action required: Before upgrading to 26.2, update any scripts or integrations that create, update or read Code Sign Manager environments or templates so that they use the PKIX parameter set fields. To update an environment, read it with POST Codesign/GetEnvironment, change the values you need, and send the whole environment back to UpdateEnvironment.

Code Sign Manager: Approve or reject pending environment changes before upgrading

Starting in 26.2, Certificate and Apple environments can have more than one Organizational Unit (OU). Because of this change, OU values in change requests submitted before the upgrade can’t be carried forward.

If a Certificate or Apple environment has a pending update request when you upgrade, the OU in that request is lost. What happens when the request is approved after the upgrade depends on how OU is controlled:

• OU isn’t locked by the environment template or policy: The environment’s OU is cleared. Certificates issued for that environment afterward won’t include an OU.
• OU is locked by the environment template: The change is rejected and the requested update is lost. The environment stays in a pending state until it’s reset.
• OU is locked by policy: The policy value is applied. No action is needed.

Before upgrading, we recommend approving or rejecting all pending change requests for Certificate and Apple environments.

If you’ve already upgraded and approved a request that was submitted before the upgrade, check the OU on that environment and set it again if needed.

SSH Manager: AuthZHelper has its own release cycle

Starting with 26.2, AuthZHelper is no longer delivered with Trust Protection Foundation. It has its own release cycle. You don’t need to upgrade AuthZHelper when you upgrade Trust Protection Foundation: each supported AuthZHelper release works with all supported versions of Trust Protection Foundation. Fixes are delivered only in the latest AuthZHelper release.

SSH Manager: SSH authorization rules API uses the sshrules scope

The SSH authorization rules API (GET /vedsdk/ssh/rules) has been replaced by (GET /vedsdk/sshrules/) and now requires the sshrules OAuth scope instead of ssh. If your script reads SSH authorization rules, update the API route, add sshrules to its integration, and request a token with that scope.

Breaking Change: Azure Key Vault now uses the Azure RBAC access model

The Azure Key Vault driver has been rebuilt on Microsoft’s current Azure SDK and follows Azure’s role-based access control (RBAC) model. Microsoft is changing the Key Vault access-control defaults, with enforcement expected in February 2027, so this change keeps Azure Key Vault applications working through that transition.

Azure Tenant ID on Azure Key Vault applications is now optional.

• Left empty: Trust Protection Foundation gets the tenant from the key vault the first time it connects, saves it on the application
• Set to the wrong tenant: the operation fails with an error that names the tenant the key vault belongs to. Correct the value and retry. A Tenant ID you set is never overwritten.

Breaking Change: CAPI default Pkcs#12 encryption algorithm changed

The default encryption algorithm CAPI uses when it builds the PKCS#12 file for provisioning changed from PBE-SHA1-3DES to PBES2-PKCS5-SHA256, for stronger key protection. Windows Server 2016 and earlier do not support anything stronger than PBE-SHA1-3DES, so they cannot import a file protected with PBES2-PKCS5-SHA256.

Action required: This affects CAPI applications that use central key generation, target Windows Server 2016 or earlier, and whose Pkcs#12 Encryption Algorithm field was left on the default rather than set explicitly. On those systems, certificate renewal and installation fail after you upgrade. Applications with an explicitly selected algorithm, and applications whose keys are generated on the target host, are not affected.

Before upgrading, open each affected CAPI application and set Pkcs#12 Encryption Algorithm to PBE-SHA1-3DES. You can do this in WebAdmin under the CAPI application settings, or in Aperture. The setting is per-application: it cannot be set on a policy folder and inherited, so each affected application has to be changed individually.

Once those hosts are on a newer version of Windows, set Pkcs#12 Encryption Algorithm back to the default so new certificates get the stronger protection.

See CAPI application driver settings.

Breaking Change: F5 LTM Advanced applications are migrated to a single Virtual Servers list

Upgrading to 26.2 runs a migration task over every F5 LTM Advanced application and policy folder. The task copies the existing Virtual Server and Partition values into the new multi-valued Virtual Servers list, renames automatically named applications after the SSL profile they use, and then removes the old Virtual Server Name and Virtual Server Partition attributes from the class.

Only applications still sitting at a name an earlier release generated are renamed. An application you renamed yourself keeps the name you gave it, and a disabled application keeps its name whether or not you renamed it. Onboard Discovery finds an application by the SSL profile it serves rather than by its name, so neither kind has to be renamed to go on being managed.

Action required: Review any WebSDK or API script that reads or sets Virtual Server Name or Virtual Server Partition, or that refers to an F5 LTM Advanced application by its DN. Those attributes no longer exist after the migration, and a renamed application has a new DN, so scripts that depend on either stop working.

Do not change virtual server assignments on the F5 while the migration is running. Let the upgrade finish, confirm the Virtual Servers list on a sample of applications, and make changes after that.

See F5 LTM application object settings.

Domain Control Validation monitoring starts on upgrade

After you upgrade, Trust Protection Foundation starts a daily check of domain control validation status against your DigiCert, Sectigo, GlobalSign, and HydrantID CA accounts, using the credentials already stored on those CA templates.

Action required: None, if those credentials are current. Before upgrading, review the credential on each DigiCert, Sectigo, GlobalSign, and HydrantID CA template. A credential that has expired, or that lacks permission to read validation data, makes the daily check log an error for that CA on every run until you update it.

Breaking Change: Existing Palo Alto Networks firewall applications need attention after upgrade

Onboard discovery for Palo Alto Networks firewalls is new in 26.2, and two known problems affect applications that already existed before the upgrade.

Action required: Before you run onboard discovery against a firewall for the first time, export or otherwise record the settings of the Palo Alto Networks applications you already have. On its first run, discovery renames and disables every application created before 26.2 and replaces each one with a copy that has default settings, so any non-default configuration is lost unless you have a record of it. Re-apply those settings to the replacement applications, then delete the disabled originals once you have confirmed the replacements provision correctly.

Separately, an existing application that provisions the firewall’s web management interface certificate fails to renew after you upgrade until you set its Binding Target by hand. Check each of those applications after upgrading and correct the binding target before the next renewal is due.

Composite signature keys from 25.1 through 26.1 are removed during upgrade

Composite (hybrid) signature algorithms pair ML-DSA with a classic algorithm such as RSA, ECDSA or EdDSA. Versions 25.1 through 26.1 implemented composite keys against an earlier draft of the IETF composite signatures specification. Version 26.2 implements draft 19 (draft-ietf-lamps-pq-composite-sigs-19), which is in the final stages before publication as an RFC. Keys in the earlier format don’t comply with the specification and can’t be converted, so the upgrade to 26.2 removes them:

• For certificates that use a composite algorithm, the private key, certificate and CSR are deleted from the Trust Protection Foundation vault.
• For key pairs that use a composite algorithm, the private key is deleted from the vault.

The certificate and key pair objects themselves aren’t deleted. After upgrading, request new certificates or generate new keys for any objects that still need a composite algorithm.

Upgrading from 24.3 or earlier: Check locked algorithm policy before upgrading

The 25.1 upgrade stage “Certificate Manager PKIX” converts locked Key Algorithm, Key Bit Strength and Elliptic Curve policy on policy folders to the new PKIX Parameter Set Policy. A folder can’t be converted if its locked policy names an algorithm that isn’t on the system-wide algorithm list, such as RSA 1024, which the default list doesn’t include. The installer and configuration finish without error, but the stage retries every few minutes and never completes. The later migration stages (25.3, 26.1 and 26.2) don’t run, so the upgrade never finishes.

Action required: This applies only if you’re upgrading from 24.3 or earlier. Before upgrading, check locked Key Algorithm, Key Bit Strength and Elliptic Curve policy for algorithms that aren’t on the 25.1 system-wide list, such as RSA 1024. Then either change that policy before you upgrade, or add those algorithms to the system-wide list during the upgrade.

If an upgrade is already stuck, look for the “Migration - Run Error” event on the “Certificate Manager PKIX” stage. The event names the folder and the algorithm. Add that algorithm to the system-wide list in the Configuration Console (Configure Allowed Algorithms), and the next retry completes the upgrade.

WebSDK changes for algorithm data (25.1 and later)

To support post-quantum cryptography and to further our goals for crypto agility, version 25.1 included a significant refactor of how algorithms are handled, at both the platform and the product level. Instead of describing a key with separate algorithm, key size and curve values, Trust Protection Foundation now identifies each key algorithm, together with its size, curve or parameter set, with a single OID called a PKIX parameter set.

In general, if your integrations read or write algorithm data, you’ll see WebSDK changes that you’ll want to adopt in order to take advantage of these new capabilities. Many of the older fields still work for backward compatibility, but they’re deprecated and support for them will be removed in a future release. Some of them also behave differently than they did before 25.1, often without returning an error. The legacy Code Sign Manager fields have already been removed in 26.2; see Breaking Change: Code Sign Manager WebSDK legacy algorithm fields removed.

Review this section if either of the following applies:

• You’re upgrading from 24.3 or earlier.
• You’re already on 25.1 or later, but your integrations still use the deprecated fields listed below.

Unless noted otherwise, each change listed here shipped in 25.1 and is unchanged through 26.2.

About PKIX parameter sets

A PKIX parameter set is an OID under 1.3.6.1.4.1.28783.10 that names the key algorithm together with its size, curve or parameter set. For example:

The WebSDK accepts only OIDs in PKIX parameter set fields, not algorithm names. For the full list, see PKIX Parameter Set in the WebSDK API reference.

Changed WebSDK endpoints

Certificates

AlgorithmSelector (new in 25.1)

AlgorithmSelector is a new module for reading and setting algorithm policy. It’s the supported replacement for writing algorithm policy through Config. It also adds a new OAuth scope, admin:algorithms.

There’s no AlgorithmSelector endpoint for a folder’s default algorithm. To set it, use Config/WritePolicy on the PKIX Parameter Set Policy Default attribute.

Codesign

New PKIX parameter set fields are on the environment and template objects that these endpoints send and return:

• Requests: POST Codesign/CreateEnvironment, POST Codesign/UpdateEnvironment, POST Codesign/UpdateTemplate
• Responses: POST Codesign/GetEnvironment, POST Codesign/FindEnvironment, POST Codesign/CreateEnvironment, POST Codesign/UpdateEnvironment, POST Codesign/EnumerateProjects, POST Codesign/GetProject, POST Codesign/CreateTemplate, POST Codesign/EnumerateTemplates, POST Codesign/GetTemplate

IMPORTANT: 26.2 removes the legacy Codesign fields. For what happens to requests that still send them, see Breaking Change: Code Sign Manager WebSDK legacy algorithm fields removed.

SSH Certificates

SSH key management

HashiCorp Vault PKI

Other

• POST SecretStore/Add: PKCS #8 and PKCS #10 data is now validated. PKCS #8 data that can’t be decoded or that’s password-encrypted is rejected with InvalidParams and a new Error response field.
• HSM API (outside /vedsdk): /vedhsm/getobjects and /vedhsm/getchain return new PkixParameterSet and PkixParameterSetName values on key objects.

Algorithm policy is stored differently in Config

If your integration uses Config to write the policy of allowed algorithms, it needs to be updated. The following attributes changed:

Be aware of the following:

• Algorithm policy is stored per schema class. The attributes above are on class X509 Certificate, which is the correct class for most certificates. To set separate policy for code signing certificates, use class X509 Code Signing Certificate. SSH objects and Code Sign Manager environments have their own PKIX Parameter Set Policy attributes. In AlgorithmSelector/GetPolicy, CommitPolicy and GetAllowedAlgorithms, SchemaClass selects which class’s policy is read or written.
• The UI and AlgorithmSelector/CommitPolicy always write PKIX Parameter Set Policy unlocked. If you lock it through Config (for example, Config/WritePolicy with Locked=1), subfolders’ own lists are ignored, so a subfolder can’t narrow it. Values the parent doesn’t allow are silently ignored when written through Config, and rejected by AlgorithmSelector/CommitPolicy with the error <algorithm> is restricted by policy.
• The old policy attributes are still in the schema, so Config/WritePolicy, Config/AddPolicyValue and similar policy calls on them return success, but they have no effect after the 25.1 upgrade has run. Write the new attributes instead, or use AlgorithmSelector/CommitPolicy. This applies to policy only: Certificates/Request still reads the old values on a certificate object that has no PKIX parameter set; see How deprecated values are converted.
• The upgrade converts only locked algorithm policy. Unlocked defaults aren’t carried over, so set PKIX Parameter Set Policy Default again after upgrading. The old values are left in place, so Config/ReadPolicy still returns them, but nothing enforces them. If you’re upgrading from 24.3 or earlier, check locked policy for algorithms that aren’t on the system-wide list before you upgrade; see Upgrading from 24.3 or earlier: Check locked algorithm policy before upgrading.
• A folder with no PKIX policy allows every algorithm on the system-wide list (PKIX Parameter Set Fallback), and folder policy can only choose from that list. By default, the list contains every algorithm with a NIST security strength of 112 or higher, so RSA 1024 isn’t included. Administrators can change it in the Configuration Console (Configure Allowed Algorithms) or with AlgorithmSelector/SetGlobalAlgorithms.
• The Config endpoints themselves didn’t change: WritePolicy, AddPolicyValue, RemovePolicyValue, ClearPolicyAttribute, ReadPolicy, ReadEffectivePolicy, FindPolicy, Read and Write.

Behavior changes to check in your integrations

Many of the following changes don’t return an error, so an integration can appear to work while producing a different result than it did before 25.1.

Certificates

• When a Certificates/Request has no key fields and no CSR, Trust Protection Foundation uses RSA 2048. The folder’s PKIX Parameter Set Policy Default is used only if policy doesn’t allow RSA 2048. As a result, drivers that generate keys on the device, such as F5, Apache, JKS and Adaptable, generate RSA 2048 keys even when the folder’s default is a different algorithm, such as ECDSA P-256. To request a specific algorithm, send PkixParameterSet.
• On a certificate that already has a PKIX parameter set, including every certificate converted by the 25.1 upgrade, the deprecated KeyAlgorithm, KeyBitSize and EllipticCurve request fields are ignored. Only PkixParameterSet changes the key.
• The deprecated request fields are no longer validated when the request is submitted. An unrecognized KeyAlgorithm is treated as RSA. An unrecognized curve name, such as P-384, is replaced by the curve that matches the bit size or, with no bit size, by P-256. A size outside the supported list produces an algorithm that isn’t supported, and the request fails during processing. For the supported values, see How deprecated values are converted. A 24.3 post-quantum preview request (KeyAlgorithm MLDSA with ParameterSet 44) now produces an RSA 2048 key. Request post-quantum algorithms with PkixParameterSet.
• If the requested algorithm isn’t allowed by policy, the policy default is used, or, if that isn’t allowed either, the first allowed algorithm on the system-wide list. This applies both to keys that Trust Protection Foundation generates and to keys generated on the device. The request fails instead when the private key is being reused, or when Trust Protection Foundation doesn’t recognize the algorithm. A user-supplied CSR whose key isn’t in the allowed list is rejected, whether or not the policy is locked. The separate “Key size error” and “Elliptic curve error” messages are now reported as “Key algorithm error”.
• In CheckPolicy, the deprecated KeyAlgorithm, KeySize and EllipticCurve fields describe only the default, and their Locked flag is always false. To find what policy enforces, read Policy.KeyPair.PkixParameterSet.
• The keyalgorithm search filter now does a case-sensitive substring match on display names such as RSA 2048 or ECDSA P-256, so keyalgorithm=ECC matches nothing. Use the pkixparameterset filter instead.
• The deprecated response fields KeyAlgorithm, KeySize, EllipticCurve and SignatureAlgorithm are empty for algorithms that have no legacy name: RSA-PSS, Brainpool and SEC curves, Ed448, post-quantum and composite algorithms. SignatureAlgorithm is also empty for RSASSA-PSS, SHA-224 and DSA signatures. One exception: GET Certificates/{guid}/PreviousVersions fills in KeySize for every key that isn’t an EC key, even where it doesn’t apply.
• GET Certificates/{guid} and GET Certificates/{guid}/PreviousVersions return two values in a new format:
  • KeyUsage: a comma-separated list of RFC 5280 key usage names in bit order, such as digitalSignature and keyEncipherment, instead of names such as DigitalSignature and KeyEncipherment.
  • EnhancedKeyUsage: Server Authentication(oid) is now serverAuth(oid).
• On Certificates/Retrieve, a PKCS #12 request without EncryptionAlgorithm defaults to Medium (PBE-SHA1-3DES). See Certificate download encryption defaults.

SSH Certificates

• POST SshCertificates/CaKeyPair/Create with no algorithm and no private key now returns 400 InvalidKeyAlgorithm. Before 25.1, it defaulted to RSA 4096. An unrecognized KeyAlgorithm becomes RSA 2048 instead of returning 400, and is then rejected with 400 InvalidKeyAlgorithm if policy doesn’t allow RSA 2048.
• For SshCertificates/CaKeyPair/Create, SshCertificates/Request and SshCertificates/Template/Retrieve, the allowed and default key algorithms now come from AlgorithmSelector policy on the container, not from a fixed list or from the SSH template’s own settings. As a result, a SshCertificates/Request whose public key uses an algorithm that policy doesn’t allow now returns error 42 (InvalidKeyAlgorithm) instead of 29 (NotCompliantWithTemplateSettings).

SSH key management

• The ViolationStatus values 14 and 15 (key size violations) were removed, because key size is now part of algorithm policy. Key size violations are now reported as ViolationStatus 7 (noncompliant algorithm). Values 14 and 15 are dropped from filters: if they were the only status values, the status filter no longer applies and all keysets are returned; otherwise, keysets that matched them are no longer returned. Filter on 7 instead. With the default system-wide algorithm list, RSA 1024 keys are reported as 7 after upgrading.
• SSH key rotation (SSH/Rotate, SSH/RotateAndWait, SSH/RotateNonBlocking) now generates the new key with the effective algorithm from AlgorithmSelector policy on the trust or device (the policy default, or the system-wide list if no default is set). Before 25.1, rotation usually kept the keyset’s current algorithm, and host keys always did. As a result, rotating an existing keyset, such as RSA 4096 or Ed25519, can now produce a key with a different algorithm. If the devices in a keyset have different effective algorithms, rotation fails with KeysetHasConflictingPolicies.

HashiCorp Vault PKI

• GET pki/hashicorp/ca/{guid} returns Certificate.KeyAlgorithm ECC for EC keys instead of ec. For algorithms that have no legacy name, including post-quantum algorithms, it omits Certificate.KeyAlgorithm and returns Certificate.KeyBitSize 0.
• GET pki/hashicorp/ca/{guid} returns the CA certificate’s effective algorithm, so the response shows the policy default (or the system-wide list if no default is set) even when the CA has no PKIX parameter set of its own.
• GET pki/hashicorp/role/{guid} returns KeyAlgorithm in lowercase (rsa, ec).
• POST pki/hashicorp/ca and PUT pki/hashicorp/ca/{guid} ignore Certificate.KeyAlgorithm unless Certificate.KeyBitSize is also supplied as a number.

Codesign

• From 25.1, environment responses normally return the legacy algorithm fields empty. If a client reads an environment, changes only a legacy field and posts it back, the change is ignored, because the PKIXParameterSet value in the body takes precedence.
• In 26.2, the legacy fields are removed, and UpdateEnvironment fails with ValueProhibitedByTemplate when the request leaves out the PKIX parameter set field. See Breaking Change: Code Sign Manager WebSDK legacy algorithm fields removed.
• In 26.2, template responses always report the PKIX parameter set policy lists as locked. A client that reads a template and posts it back writes the policy as locked.

How deprecated values are converted

The following areas still accept the old algorithm values and convert them to a PKIX parameter set OID as they’re processed. They all use the same mapping:

• RSA (also rsaEncryption or its OID) with a size of 1024, 2048, 3072, 4096 or 8192. With no size, it becomes RSA 2048.
• ECC or EC (also ecPublicKey) with curve P256, P384 or P521. Curve names aren’t case-sensitive, but other forms, such as P-384 or secp384r1, aren’t recognized. With no recognized curve, the bit size (256, 384 or 521) picks the curve; otherwise, it becomes P-256. Use P256, P384 or P521 (no hyphen), or send PkixParameterSet.
• ED or ED25519 becomes Ed25519.
• DSA follows the same rules as RSA, with sizes 1024 through 4096.
• Any other value is treated as RSA, unless the table notes otherwise. No error is returned, so an integration that sends an unexpected value, such as ECDSA, gets an RSA key.
• An RSA or DSA size that isn’t in the lists above, including a size sent with an unrecognized algorithm (for example, ECDSA with 384), produces an algorithm that isn’t supported. The request is accepted, but it fails during processing. Use a listed size, or send PkixParameterSet.

Any integration path not listed here, such as Config/WritePolicy on the old attributes, isn’t converted. See Algorithm policy is stored differently in Config.

Certificate download encryption defaults

Version 25.1 added the EncryptionAlgorithm field, which sets how the private key in a downloaded certificate file is encrypted. It applies to POST and GET Certificates/Retrieve, POST and GET Certificates/Retrieve/{VaultId}, the inline retrieve on POST Certificates/Request, and POST Certificates/Renew (26.2 and later). The defaults, and how they interact with the Certificate Download policies, changed in these releases:

• 25.1.0: When EncryptionAlgorithm is omitted, the WebSDK uses Medium for every format.
• 25.1.1: The Medium default applies only to PKCS #12.
• 25.1.7, 25.3.2 and 26.1.0: WebSDK downloads honor a locked Certificate Download: Pkcs12 Algorithm policy. Before these versions, only the UI did.
• 26.2: POST Certificates/Renew accepts EncryptionAlgorithm.

If you’re upgrading from 25.1.0 through 25.1.6, or from 25.3.0 or 25.3.1, a locked Certificate Download: Pkcs12 Algorithm policy starts to take precedence over the EncryptionAlgorithm value your integrations send.

Set EncryptionAlgorithm to a strength (Medium, Strong or Super) from the following table, or to an encryption algorithm name listed for EncryptionAlgorithm in the WebSDK API reference.

Be aware of the following:

• For PKCS #12, the WebSDK uses Medium whenever EncryptionAlgorithm is omitted. This keeps 25.1 output close to earlier releases (3DES key encryption), but it also overrides an unlocked Certificate Download: Pkcs12 Algorithm policy (new in 25.1). A locked policy takes precedence (for WebSDK downloads, from 25.1.7, 25.3.2 and 26.1.0). The same applies to the Certificate Download: PBES2 Algorithm policy for the Base64 formats.
• Before 26.2, POST Certificates/Renew has no EncryptionAlgorithm field, so a PKCS #12 file returned by a renewal uses Medium unless a locked Certificate Download: Pkcs12 Algorithm policy applies (from 25.1.7, 25.3.2 and 26.1.0).
• PKCS #8 defaults to Strong only when no Certificate Download: PBES2 Algorithm policy is set; otherwise, the policy value applies.
• AES-256-CBC in the OpenSSL PEM format still uses MD5 key derivation, so Strong and Super don’t add PBKDF2 protection in that format. For PBKDF2, use Base64 (PKCS #8).

Recommendation: We anticipate changing the PKCS #12 download default from Medium to Strong (PBES2 with AES-256) in a future release. Set EncryptionAlgorithm explicitly now instead of relying on the default:

• Use Strong or Super wherever the consuming application supports PBES2/AES PKCS #12 files.
• Use Medium only where a consumer can’t read AES-encrypted PKCS #12 files, such as Windows Server 2016 and earlier and older Java or OpenSSL versions, so that the output doesn’t change when the default does.

New in version 26.1

Breaking Change: DigiCert Email Address Validation

Email Subject Alternative Names (SANs) are now required for both Client and S/MIME certificate types.

If you have existing certificate policies or workflows that allow Client certificates to be issued without an email address, those requests, including automated renewals for existing certificates, will fail after upgrading to 26.1. Before upgrading, please take the following steps: - Review your DigiCert CA templates and Client certificate policies. - Ensure all certificate requests for both Client and S/MIME types are configured to require an email address in the SAN. - Update any automated scripts or workflows that request these certificate types to ensure they are passing an email address. - Identify any existing Client certificates currently deployed without an email SAN, as they will need an email address added prior to their next renewal.

See DigiCert Central requirements.

SSH Discovery: Dynamic Home Directory Resolution

Starting in 26.1, Trust Protection Foundation no longer assumes user home directories are under /home/{USER}. It now looks up each user’s real home directory—matching OpenSSH’s own logic—using the system user database (for example /etc/passwd, or directory services like LDAP/NIS through standard system lookups such as getent passwd).

Because of this change, authorized keys in non-standard or network-mounted home directories (for example NFS homes) that were previously shown as Idle may now be shown as Authorized.

After you upgrade, you may see a change in these numbers in SSH Keyset Inventory after the first discovery scan.

See Discovering authorized SSH keys using sshd_config.

FTP report delivery is no longer supported

Starting in 26.1, FTP is no longer available as a delivery method for legacy reports or custom reports. This change addresses security concerns, as FTP transmits credentials in cleartext over the network.

Action required: If you have reports configured for FTP delivery, you must reconfigure them to use one of the following secure alternatives:

• Windows Share - Delivers reports to a network share using SMB/CIFS protocol
• SFTP (SSH File Transfer Protocol) - Delivers reports securely over SSH

To update your report delivery settings:

1. Navigate to the report configuration in the administrative console
2. Locate the delivery settings
3. Change the delivery method from FTP to either Windows Share or SFTP
4. Update the connection credentials and path as needed

Updated Code Sign Client Versioning and Distribution

To improve your organization’s security posture, the Client Distribution page and the client’s --update flag now retrieve the latest client version from a public distribution endpoint, by default. This ensures your organization always has access to the most current client, including the latest security fixes and patches. The Code Sign Client now supports both Code Sign Manager - Self-Hosted and Code Sign Manager - SaaS, and is no longer bundled with Certificate Manager installation files.

If your organization does not want to use the public distribution endpoint, you can disable it after a complete upgrade or install. Note that disabling this option means your organization will not automatically receive the latest client updates, security fixes, or patches. For details on managing client distribution, see Managing Code Sign Client distribution.

In addition, the Code Sign Client now uses a date-based versioning format (yy.mm.dd.build). Learn more.

SCIM identity connectors and SAML configuration changes

Trust Protection Foundation 26.1 adds SCIM 2.0 support for modern identity providers. Two changes from this work affect customers upgrading to 26.1.

Automatic SAML configuration move (applies to all SAML customers)

The legacy SAML code path has been removed in 26.1. During upgrade, your existing SAML configuration is automatically moved onto the highest-ranked non-local identity connector. After upgrading, confirm that your SAML-based SSO login still succeeds.

Authenticating SCIM-provisioned users to clients and snap-ins

SCIM-provisioned users may not have a local password in Trust Protection Foundation, so they cannot authenticate to clients that previously required a username and password. SCIM-provisioned users sign in to the following via the OAuth 2.0 Device Authorization Flow:

• MMC snap-ins — OAuth 2.0 sign-in for SCIM-provisioned users. Username/password sign-in continues to work for users who still have local credentials.
• Code Sign Client — pass the --device option to trigger the OAuth 2.0 Device Authorization Flow. Required for SCIM-provisioned signers.
• AuthZHelper — OAuth 2.0 Device Authorization Flow for the same reason.
• WebSDK — SCIM-provisioned users obtain an OAuth grant for WebSDK access via the OAuth 2.0 Device Authorization Flow.

Local accounts remain enabled after upgrade

In previous releases, configuring SAML SSO disabled local account login—SAML was the only way to sign in. Starting in 26.1, Trust Protection Foundation supports multiple SSO methods at the same time, and local accounts remain enabled and available for sign-in alongside any SSO configuration. This applies whether or not you use SCIM. To prevent local accounts from being used to log in, disable each local user account individually.

See Configuring a SCIM connector.

Unassigned certificates now stay licensed once managed

Starting in 26.1, Trust Protection Foundation permanently tracks whether a certificate has ever been managed. The first time a certificate’s management type is set to Monitoring, Enrollment, or Provisioning, the certificate is flagged as having been managed. This flag is set during nightly tasks and is one-way — once set, it is never cleared.

License counting is now based on this flag rather than on the certificate’s current management type. As a result, a certificate that has ever been managed continues to count toward your license even if it is later returned to Unassigned. The web interface prevents you from setting a previously managed certificate back to Unassigned; policy-lock or Web SDK overrides visually show Unassigned, but the certificate remains licensed.

What this means for you: Unassigned is intended as a temporary triage bucket for newly discovered certificates, not as a way to keep certificates alive but unlicensed over the long term. If you previously relied on returning certificates to Unassigned (for example, by locking a policy folder to Unassigned during renewal periods) to reduce your license count, that approach no longer lowers your count after upgrading to 26.1.

See Unassigned certificates.

New in version 25.3

Breaking Change: MSI installer file names updated

As part of our ongoing rebrand of Venafi products into the CyberArk portfolio, several MSI file names have changed in this release. If you use scripted installations or upgrades, you will need to update your scripts with the new MSI files.

Note: XX.X.X represents the product version number.

In this release folder and installation path names remain changed, as do component names, so you can continue to use existing Answer Files.

WebView2 runtime requirement

Starting in version 25.3, Venafi Platform no longer includes the Microsoft Edge WebView2 runtime. You must install WebView2 on all target servers before installing or upgrading to 25.3 or later.

Venafi Platform now uses the system-installed WebView2 runtime instead of bundling fixed embedded libraries. This reduces the installer size and ensures you are always running the latest secure version of the runtime.

If you use deployment images or automated provisioning tools, update them to install the WebView2 Evergreen runtime.

You can download the Microsoft WebView 2 Evergreen Runtime from Microsoft Edge WebView2 - Microsoft Developer.

Additional resources

• Distribute your app and the WebView2 Runtime – Microsoft Docs
• Detect if a WebView2 Runtime is already installed - Microsoft Docs

Breaking change: Reset Code Sign Client after upgrading to version 25.3

If you use the macOS tkdriverconfig Code Sign Client, you must reset the client after upgrading to version 25.3. Resetting requires the following steps:

1. Revoke all existing grants for tkdriverconfig,
   
2. Delete trusted certificates, and
   
3. Re-establish trust and request a new grant.

1. Revoke existing grants

tkdriverconfig reset --all

2. Delete trusted certificates

Delete the user certificate store file at /Users/<username>/.libhsmtrust.

3. Re-establish trust and request a new grant

tkdriverconfig getgrant

NOTE: If you had previously established trust with Code Sign Manager servers other than the one used by tkdriverconfig, you’ll need to re-establish that trust. You can do that using the gpgconfig trust and pkcs11config trust commands.

Update filenames for Code Sign Client installers

Code Sign Client installer filenames have changed. Update any automation that relies on the old filenames.

SSH Manager for Machines

Users of SSH Manager for Machines, formerly SSH Protect, should consider the following details when upgrading to 25.3 and/or using the new AuthZHelper utility and SSH Authorization Rules features.

• A dedicated Trust Protection Foundation instance is recommended when using the AuthZHelper and SSH Authorization Rules feature. This is due to increased overhead related to SSH Authorization frequency.
• When using the AuthZHelper and SSH Authorization Rules feature, note that Agentless Discovery may incorrectly report authorized keys when AuthZHelper is enabled. This is because AuthZHelper uses its own configuration to specify the locations of authorized keys files, which may differ from the locations that the agent scans. As a result, the agent may not detect authorized keys managed by AuthZHelper, leading to discrepancies in reported key data.
• Because SSHD is configured with AuthorizedKeys set to ‘none’ when using AuthZHelper, the agent does not detect any authorized keys. Instead, AuthZHelper uses its own config.yaml to identify authorized keys, which can cause keys to appear mis-labeled or as public keys.
• AuthZHelper instances use a copy of the Trust Protection Foundation host’s TLS certificate to authenticate. This should be manually added to the AuthZHelper client’s config folder and can be monitored and rotated using Trust Protection Foundation. Alternatively, if Trust Protection Foundation is utilizing a certificate that is trusted by the client’s OS, then the api-cert reference is not needed.
• AuthZHelper is not compatible with EC2 Instance Connect. This is due to both tools making use of the AuthorizedKeysCommand directive.
• AuthZHelper is not compatible with the ‘match’ option in SSHD. If your organization uses this configuration, we recommend consulting with Palo Alto Networks’ Professional Services team to review before installing or modifying your sshd_config.
• SSH connection ‘Options’ (see SSH Man > Options) will be passed to AuthZHelper and then to SSH. This follows the SSH code flow in that options are added together as they are encountered (for example from TrustedUserCAKeys, then again from AuthorizedPrincipalsFile). In the event that there are conflicting options, AuthZHelper will DENY the connection with a log entry, “Conflicting options detected.”
• Known issue: If a user has configured their authorized_keys file with conflicting SSH Options (i.e. no-port-forwarding with permit-listen=“[HOST]:PORT”), the default behavior of SSHD is to try and reconcile those options, generally preferring the most restrictive result. However, some combinations are considered invalid by SSHD (i.e. multiple command= options). Any such “invalid” combination will result in a failed login by SSHD. In these cases, SSH Manager will reflect an “observed” rule indicating that the account does have access to the host. This choice was made to show all potential accesses in the ruleset, even if SSHD would ultimately deny those attempts due to the user’s misconfiguration of authorized_keys.

New in version 25.1

Algorithm changes across platform products

Trust Protection Platform 25.1 introduces broad support for over 100 algorithms across product lines. Be aware of the following:

• Upon upgrade you will be asked to determine which algorithms you want to support. The algorithms you select will be available across the product. You can restrict these to a subset for individual policy folders.
• In prior versions, if you wanted to specify an algorithm at the policy level, you could only specify a single algorithm. Starting with 25.1, you can provide a list of allowed algorithms for a given policy. If you want to further restrict this list at a lower policy level, you can, but you can’t select any algorithms disallowed by the higher-level policy.
• The default algorithms list is in priority order. If you have a certificate using an algorithm that is no longer permitted by policy (or by the global available algorithms list), the highest priority algorithm that is allowed by policy will be used for the renewal. Because of this pay attention to the order of algorithms in the allowed algorithms list when you select them as part of your upgrade.

Certificate chain building procedure changes

The logic for building certificate chains between versions 24.3 and 25.1 has been improved. As a result, the chains created during pushing, pulling, or downloading may change after upgrading.

PKI administrators should review the Certificate Chain Preferences tab on each CA Template and ensure the correct chain is selected. If the Automatic option does not provide the desired chain, manual adjustments may be necessary.

For more info, see Understanding CA template chaining.

Update certificate policy for PKIX and WebSDK

In version 25.1 there have been significant changes to the API calls for certificate requests. If you want to use the newly-supported algorithms, you will need to use the new API calls with the appropriate OID. If you are using the old versions of the API calls, there is currently support for backwards compatibility. However, even if you don’t want to support the new algorithms, you will want to develop a migration path because support for the older API methods will eventually be removed.

When using our WebSDK to specify policy of an algorithm, this is now stored differently in config and is viewed as a breaking change in some uncommon use cases. If your integration is using config to write the policy of allowed algorithms, then your WebSDK integration code will need to be updated for upgrades to 25.1 and beyond.

For the list of affected WebSDK endpoints and behavior changes, see WebSDK changes for algorithm data (25.1 and later).

Data value changed to binary format

As part of the upgrade from versions 22.2 through 24.3, the Data value for the ‘Disabled’ attribute was changed from a binary format to a base64 encoded string. In version 25.1, we have reverted this change, and the Data value is now logged in its previous binary format.

EST-specific revocation settings

EST-specific revocation settings have been removed from the EST Work Settings section. EST Server now adheres to revocation settings defined for Trust Protection Platform via WebAdmin.

SSH Protect upgrade considerations

UI updates: The Default Private Key Algorithm and Allowed Private Key Algorithms are now configured for target policies via the “Create Certificate Object in Folder” option in the “SSH Certificate Template(s)” section. Previously, this configuration was managed via the “SSH Certificate Issuance Template” pages.

Tip: To adhere to certificate lifecycle management best practices, review and adjust the “Create Certificate Object in Folder” value within the “SSH Certificate Issuance Templates” section.

Key validation: Discovered keys are validated against the Allowed Algorithms list, which is defined by its corresponding policy.

SSH key and certificate settings: The policy settings Algorithm and Allowed Algorithms now affect both keys and certificates. - Keys: Existing policy settings are migrated to version 25.1. No action is required from customers for key generation. The same algorithm used in 24.3 will be used in 25.1. - Certificates: Template settings have been removed. Settings are now managed by the folder specified in the field Create Certificate Object in Folder. Customers should check the Algorithm and Allowed Algorithms specified in the folder. The same settings apply to keys issued under this folder.

Changes in certificate management

• Certificate settings moved from CA template to policy settings.
• Allowed algorithms for certificates are now controlled by policy settings.
• Future updates will remove key size information entirely.

Experimental post-quantum (PQ) keys invalidated

PQ algorithm support has been updated to the final FIPS 204 (ML-DSA) and 205 (SLH-DSA) standards. These changes made to the Trust Protection Platform will require all experimental PQ keys and certificates to be invalidated. All PQ keys will need to be regenerated after upgrade to 25.1.

• PQ keys used by CodeSign Protect single-user keypair environments will be automatically regenerated whenever a CodeSign Protect client retrieves the object list.
• PQ keys used by Server Certificates or by CodeSign Protect single-user certificate environments will need to be manually renewed via the UI or API.
• CodeSign Protect per-user environments will need to be manually deleted and re-created.
• Enabling “PostQuantum Experimental” in the Windows Registry is no longer necessary. PQ algorithms are now available by default.
• The standard for Composite keys has not been finalized yet, so those keys may need to be invalidated in a future release.

For a list for all supported algorithms, see Algorithm types supported by Trust Protection Platform.

CodeSign Protect statistics

The statistics providing data for the “All signings for the past” dashboard will be migrated during the upgrade process. The data will be incorrect on that dashboard until the following conditions have been met:

• The last Trust Protection Platform server has upgraded to 25.1.
• The statistics rollup that runs at the top of the hour has completed.

New in version 24.3

Breaking change: Updated parameter names in POST /vedsdk/codesign/RetrieveArchiveEntries

With the introduction of the CodeSign Protect Archive UI, several enhancements were made to the POST /vedsdk/codesign/RetrieveArchiveEntries REST endpoint. These enhancements include renaming of two parameters:

• Status is now EventType
• EventId is now EventTypeId

Any automations that rely on these parameters will need to be updated after upgrading to 24.3.

New Windows Dependency Requirements

There is a new system requirement for all Windows servers, including those upgrading. Though this is listed in the system requirements in the Server Configuration Requirements section, users who are upgrading from a prior release should be aware that there are two Visual C++ Runtime libraries you need to download and install from Microsoft before you install Venafi Platform.

You need to install both the 32-bit and 64-bit libraries.

By installing these libraries separately from Venafi Platform, Microsoft Update can provide security or other updates to these libraries without requiring an update of Venafi Platform.

Experimental post-quantum (PQ) keys invalidated

Post-quantum (PQ) cryptography standards continue to evolve. Changes made to the Trust Protection Platform experimental post-quantum implementation will require all PQ keys and certificates to be invalidated. All PQ keys will need to be regenerated after upgrade to 24.3.

• PQ keys used by CodeSign Protect single-user keypair environments will be automatically regenerated whenever a CodeSign Protect client retrieves the object list.

• PQ keys used by Server Certificates or by CodeSign Protect single-user certificate environments will need to be manually renewed via the UI or API.

• CodeSign Protect per-user environments will need to be manually deleted and re-created.

Venafi will continue to improve support for PQ algorithms. Additional changes will be made in Trust Protection Platform 25.1 that will require the 24.3-created PQ keys and certificates to be invalidated at 25.1 upgrade.

Database Compatibility Level

With the deprecation of support for Microsoft SQL Server 2012, we also no longer support database compatibility level 110 (SQL Server 2012) or older. When you upgrade your SQL Server databases, be sure your database settings are updated to match the compatibility level of the version you are using.

New in version 24.1

Updated TPP 24.1 upgrade processes

When upgrading to TPP 24.1, you should follow the same decision-making strategies, preparation tasks and upgrade procedures you use for typical TPP server upgrades. See Upgrading Venafi Platform.

However, please note that when upgrading to TPP 24.1, you will see two differences from the typical upgrade process: (1) an enhancement to the TPP 24.1 installation program called PreFlightTool that reports the platform’s readiness to upgrade, and (2) a temporary suspension in operations during the upgrade’s final migration processes. For more information, see Updated TPP 24.1 Upgrade Processes.

Breaking change: Kubernetes Discovery Jobs and TLS Protect for Kubernetes

Venafi is transitioning from the TLS Protect for Kubernetes platform to the TLS Protect for Kubernetes module within the Venafi Control Plane. This update improves machine identity management for your Kubernetes environments.

Important action required: Before the upgrade, verify if your TLS Protect Datacenter instance has existing Kubernetes Discovery jobs. After the update, these jobs will no longer be compatible with the TLS Protect for Kubernetes platform. Delete any Kubernetes Discovery jobs before the upgrade to ensure a smooth transition. Contact your Venafi representative for more details and assistance.

Message Bus

A new requirement in 23.3 and continuing in 24.1 is that a Message Bus/MQTT framework must be available for services to function properly. On Upgrade you will be required to choose between a Self-Hosted (mesh network topography style) that is self managed by Venafi or a Central MQTT Broker (hub-and-spoke network topography style) that your organization provides.

Most customers will choose the self-hosted option, but requires that the configurable/default port of 8883 be accessible between all Venafi servers. If your network team is not able to accommodate this requirement, then it is recommended to investigate your organization providing a central MQTT broker that your organization is responsible for. If you have questions about how to plan for this requirement, please reach out to your Customer Success representative or Account Team.