Venafi Trust Protection Platform version 19.2 introduces some significant enhancements across the product line.
IMPORTANT! Before upgrading to version 19.2, carefully review the topic, Important Considerations Before Upgrading to Venafi Platform 19.2.
Venafi Next-Gen Code Signing – New Product
Venafi Next-Gen Code Signing secures enterprise code signing processes by providing centralized key storage and policy enforcement while also reducing the burden on development teams.
- Delivers enterprise-wide visibility of code signing activities
- Enforces and automates code signing policies and certificate usage
- Secures code signing private keys
- Integrates with popular CAs, HSMs and software development tool chains
By combining visibility and intelligence with workflow automation and controls, Next-Gen Code Signing protects against unauthorized use of code signing certificates while providing an audit trail of all code signing activities.
Benefits include the following:
- Eliminates risks from unsecured private keys and private key sprawl
- Ensures code signing security with policy enforcement and reporting
- Improves efficiency through distributed signing and automation of requests and approvals
- Eliminates code signing delays
New interfaces are included to administer Venafi Next-Gen Code Signing:
- Venafi Code Signing node in Venafi Configuration Console
Code Signing Administrators use this node in Venafi Configuration Console to set global code signing defaults and restrictions. The Venafi Code Signing node can be run remotely as an MMC Snap-in. - New Role-Based Service UI
Code Signing Project Owners, Administrators, and Key User Approvers use this interface in Aperture to request new projects, approve new projects, and approve use of code signing keys.
In addition, we are introducing a Cryptographic Service Provider (CSP) that can be installed on Windows workstations from which code will be signed. The Venafi CSP communicates over REST with the Trust Protection Platform server for authentication and code signing requests. In this release, Venafi Code Signing supports RSA-based signing for both SHA1 and SHA256 hashes.
Venafi Code Signing is a separately licensed product. If you’re upgrading from a previous version of Trust Protection Platform, see Enabling Venafi Code Signing after upgrading.
- Venafi MMC Snap-in Collection
A new Snap-in collection is introduced that allows the new Venafi Code Signing and Venafi Event Viewer MMC snap-ins to be installed and run remotely. This is made possible by a new API Host Windows Service. This service is a WCF self-hosted web service used to run the Code Signing Admin and Event Viewer MMC snap-ins on the Trust Protection Platform server.
See Venafi Windows services.
Venafi Platform
- Amazon Web Services RDS MSSQL Support
For customers hosting TPP in AWS, their RDS cloud Database Product is now supported for hosting the Venafi Trust Protection Platform.
See Supported Databases in System Requirements.
Note: Support for SQL 2012 and SQL 2014 will be deprecated in TPP 19.4. SQL 2016 SP1 will be the minimum version - Administrators Node
The Administrators node adds the ability to assign additional Master Admin and Code Signing Administrator users from the Venafi Configuration Console. Assigning Code Signing Administrators requires a Venafi Next-Gen Code Signing license.
See Administrators. - Identity Connector Configuration
The Identity tree selector in WinAdmin has been moved to the Venafi Configuration Console (VCC). Active Directory and LDAP Identity connection wizards and configurations are now launched from the Connectors node in VCC.
See Creating an Active Directory connection.
See Creating an LDAP connection. - Rotate Active Directory and LDAP Service Credentials through CLI
Leveraging the TppConfiguration.exe utility, you can programmatically change the service password by leveraging the -identitypwd switch. - Venafi Event Viewer
The Venafi Event Viewer node provides advanced logging/event viewing capabilities. This node can be run remotely as an MMC Snap-in.
See Venafi Event Viewer. - Improved Management of MasterAdmin and WebSDK roles
Within the Aperture Identities menu, Master Admins now have better visibility and management of Master Admin and WebSDK Roles through new filtering and bulk actions. - Attention Required
This node provides an overview of potential Trust Protection Platform configuration issues that should be addressed.
See Attention Required. - SMTP Connector Configuration
SMTP server defaults used for reporting and logging can be configured from the Connectors node in Venafi Configuration Console.
Information related to this feature is under development. Until it is ready, you can see configuration information in Configure SMTP settings. This topic discusses SMTP in context of the Venafi Code Signing product, but the configuration is the same, even if you don’t have Code Signing enabled. - Online Migration framework
The new framework allows data migration while Trust Protection Platform services are running. - Update in how license usage and other telemetry are sent to Venafi
We are always looking for ways to build better products for you, and to help you more effectively if you run into an issue.
To that end, we collect telemetry to ensure your Venafi products are secure, perform as expected, and ultimately help you be more successful. This telemetry includes both technical and interaction data and is not personally identifiable information.
When you entrust us with this information, it remains yours. We do not sell or otherwise provide your data to third parties for advertising or promotional purposes. Your privacy, your trust, and your success are paramount to us.
For more information, please see the Venafi Privacy Policy.
Certificate Driver Integrations
- Onboard Discovery support for Amazon Web Services and Azure Key Vault
Certificates in AWS and Azure accounts can now be rapidly discovered along with all configuration necessary to validate and take control of their renewal lifecycle.
See Creating a new Onboard Discovery job. - Support for Amazon Web Services cross-account access
Trust Protection Platform can now use the AWS AssumeRole feature to access multiple AWS accounts using a single credential. This configuration lets you authenticate to a single AWS account and execute different types of work—provisioning, Onboard Discovery, and Cloud Instance Monitoring—across any other AWS accounts in which you've added the same cross-account role.
See Authenticating to multiple AWS accounts using a single Amazon Credential. - Binding certificates to an Azure Key Vault application
You can now configure Trust Protection Platform to bind your certificates to web applications automatically during provisioning so that you don't have to create the binding using other methods.
See Creating an Azure Key Vault object in Trust Protection Platform. - Added support for provisioning ECC certificates using JKS driver
This release adds support for provisioning centrally and remotely generated (non-HSM) elliptic curve certificates (ECC) to Java key stores.
Server Certificate
- Outage Risks are highlighted in New Validation widgets on All Certificates Dashboard
There are three new widgets available on the All Certificates dashboard, showing counts for protocol, end entity validation, and chain validation with colors to represent potential risks that require attention. You can click either the bubble or the legend to be taken to a filtered list of certificates that match that condition.
See Chain Validation widget.
See End Entity Validation widget.
See Secure Protocols vs Insecure Protocols widget. - Improved Revocation Checking
In previous versions of Trust Protection Platform, the revocation checking feature was not performant, and many customers were instructed to disable this feature for improved performance. In 19.2, revocation checking has been totally refactored, and this module is now recommended for customers of all environment sizes. Revocation checking is a feature that checks every certificate in inventory on a scheduled basis to see if the certificate has been listed on a Certificate Revocation List (CRL). If a CRL is not available for a certificate, it checks via OSCP. Notifications related to revocations will be sent to certificate owners so they can take any appropriate action, if necessary.
See About Revocation Checking. - CRL and CDP checking
Ensuring your certificate validation statuses match the status of the certificate on the CA is important. If a CRL expires or is unavailable, it can cause multiple system outages for all systems with certificates that rely on that CRL Distribution Point (CDP) for verification. Trust Protection Platform checks the CDPs on a scheduled basis to verify that the endpoint is active. If a CDP goes down, you need to take immediate action to prevent outages. The Trust Protection Platform Certificate Revocation List (CRL) Verification Service verifies CRLs to ensure that they are valid and available for revocation checking. If a CRL is within a configurable time-period prior to expiration, the service sends a notification to one or more administrators so that they can ensure it is updated.
See Validating Certificate Revocation Lists. - New Validation Filter section
Enhancements in 19.2 allow you to filter on protocol, end entity validation, and chain validation from the Certificate Inventory list.
See SSL/TLS network validation.
- TLS Endpoints Column in Aperture
A new TLS Endpoints column in the Certificate inventory in Aperture has a drop-down that allows you to see all the TLS endpoints for a specific certificate, right from the inventory. This sub-table shows IP Address, port, enabled protocols, results of SSL/TLS validation and results of Chain validation for that endpoint.
See Editing columns in the Certificate Inventory list. - Improved Filtering for Jobs List
In addition to filtering on the job type, you can now filter on the job status and when the job last ran.
SSH
- New Reports for SSH
The SSH keyset details page now allows you to create a report of Authorized keys and Private keys, which data can then be exported to other BA tools for analysis. There is also a new Authorized Users custom report available in the Reports menu in Aperture.
See Analyzing the SSH Authorized Users report - Highlight environment crossing in SSH keysets
When you create or edit a device, you can now specify the environment that device is in (for example, development, testing, production, etc.). If a keyset has an authorized key in one environment and a private key in a different environment, Aperture will display a security warning on the keyset and it displays as a risk in the SSH key inventory.
See Keyset details
See SSH policy settings details
Enterprise Mobility Protect
- Support for DigiCert CertCentral CA for user certificates
You can now request and retrieve certificates for email protection or client authentication from DigiCert CertCentral CA.
For more information, see Enterprise Mobility Protect: Supported platforms and requirements. - Support for Symantec MPKI via Adaptable CA for user certificates
You’re able to request and retrieve certificates for email protection or client authentication from Symantec MPKI CA via the Adaptable CA script.
For more information, see Using the sample Symantec Managed PKI Service PowerShell script. - Tag imported certificates based on their origin
Certificate Import functionality is now enhanced with an option to "tag" certificates by their origin. Once certificates are tagged, the Administrator can see statistics like trends and total numbers on the User and Client Device Certificates dashboard.
For more information, see Configuring a certificate import using Adaptable CA and Configuring a certificate import from a Microsoft CA.
TrustNet™
- Improved phishing certificate detection notifications
Enterprise security operations teams can now receive notifications for potential phishing domains. Notifications are delivered directly to team members’ inboxes for quicker resolution of security incidents.
For more information, see TrustNet dashboard graphs.
- New TrustNet-specific certificate tags that leverage the placement rules engine
Automated placement of certificates into the proper folders allows administrators to organize and sort the large numbers of relevant certificates found using TrustNet’s “outside-in” approach to global discovery. Because TrustNet can place certificates in the proper folders based on certificate attributes, this feature helps drive follow-up remediation actions.
For more information, see Creating TrustNet placement rules.
- Identify and filter all phishing certificates
Enterprise security operations teams can now filter and view all phishing certificates in one place in Aperture. The Administrator can also generate automated placement of certificates into specific folders based on the Phishing_Certificate_All tag. This allows administrators to organize and sort the large numbers of phishing-related certificates in order to perform bulk certificate actions.
For more information, see Creating TrustNet placement rules.
API Integrations
- Token Authentication for WebSDK (REST API)
19.2 introduces a new mechanism (POST Authorize/OAuth) to get long lived API tokens that are used for making REST API calls. These new tokens have a longer lived validity (default 90 days) and can be used across all WebSDK enabled Venafi servers for better high availability of WebSDK services.
To support Token Authentication, a new Authentication IIS service must be added in the Venafi Configuration Console after upgrade. To manage authentication to the Authentication server, a new Remote Access Tree is available. This view manages token and grant validity, as well as enabling different authentication methods (Password, Windows Integrated, and Certificate).
See Setting up for Token Authentication.
See 19.2 Important Considerations before enabling the Authentication Server in Venafi. - Credentials and Metadata interfaces added to Swagger specification
You can now use Swagger to test development that reads and modifies Trust Protection Platform Credentials and Metadata (Custom Fields).
See Trying out the Web SDK in Swagger. - GET and HEAD Certificates API self-signed certificate search filter
A new attribute filter allows GET and HEAD Certificates API calls to include or exclude self-signed certificates from the response.
See Certificates attribute filters. - GET and HEAD Certificates API wildcard search filter
A new attribute filter allows GET and HEAD Certificates API calls to include or exclude certificates based on whether the certificate CN or DNS SANs are wildcards.
See Certificates attribute filters. - GET Certificates/{guid}/PreviousVersions API provides certificate version information
The new GET Certificates/{guid}/PreviousVersions API call returns details about previous versions of a certificate.
See GET Certificates/{guid}/PreviousVersions. - GET and POST Certificates/Retrieve/{vaultid} APIs retrieve a certificate and other information
The new GET and POST Certificates/Retrieve/{vaultid} API calls download a certificate based on the Vault ID optionally including private key and chain certificates.
See GET Certificates/Retrieve/{vaultid} and POST Certificates/Retrieve/{vaultid}. - GET Log/{guid} to view log events for a specific object
Previously available, this method is now added to documentation so callers can see the log events to any object they have view and read permissions to.
See GET Log/{guid}.
Server Agent
- Windows Server 2019 support
The Venafi Server Agent is now supported on Windows Server 2019, in addition to the many existing supported platform.
See Venafi Server Agent requirements listed under “Server Agent and Enterprise Mobility Protect User Agent” in System requirements for Venafi components. - iPlanet NSS database discovery support
The Server Agent now supports the Network Security Services (NSS) database format used for Oracle iPlanet Web Server. - New Randomized delay helps minimize impact on server resources
This new command-line options is designed to minimize the impact that the Server Agent might have when you've got many systems running the Server Agent but that need to be restarted simultaneously. Applying a check-in delay to those agents can help you avoid overloading the systems during the reboot.
See Server Agent command line reference.
Comments