Applies to:
Upgrades to Venafi Trust Protection Platform 18.1
Summary:
Venafi Trust Protection Platform 18.1 introduces new functionality and several changes to existing functionality. Click here for a complete list of new features.
IMPORTANT! Before upgrading, read through this article carefully. Depending upon the version you are upgrading from, several of the enhancements to Trust Protection Platform over the past two years require action on your part, either prior to upgrading or immediately after.
Pay special attention to the list of features that have been deprecated, and to the list of features scheduled for deprecation.
For detailed upgrade steps, refer to the Readme.rtf document that is packaged with Venafi Trust Protection Platform 18.1 installation files.
For more information about the Venafi Trust Protection Platform product life cycle, visit Venafi Product Life Cycle.
More Information:
Deprecation of Windows Server 2008 R2
With the release of Trust Protection Platform 17.4, support for Windows Server 2008 R2 was removed. Trust Protection Platform 18.1 takes advantage of new functionality available in Windows Server 2012 and 2016. Therefore, you can no longer install on Windows Server 2008 R2. Please upgrade or replace your Windows systems with Windows 2012 R2 or Windows 2016 servers before attempting to upgrade to Trust Protection Platform 18.1.
Deprecation of Microsoft SQL 2008 R2
Before upgrading to Trust Protection Platform 18.1, verify that the Microsoft SQL Server hosting the Trust Protection Platform database is running Microsoft SQL Server 2012 SP2, 2014, or 2016 with the latest patches applied.
For more information, see Error: "This Upgrade Is Not Allowed Due To An Incompatible Version Of SQL Server"
Venafi Advanced Key Protect Required for HSM Remote Key Generation
If you have been provisioning certificates with keys remotely generated in a Gemalto SafeNet HSM and want to continue doing so, you must enable Advanced Key Protect after upgrading to Trust Protection Platform 18.1
Upgrade Process - Windows Services
Trust Protection Platform 18.1 includes a new and enhanced install and upgrade process. Following an upgrade, the new installer does not start Venafi Windows Services automatically. Instead, use the new Venafi Configuration Console on the Product Node to start and stop services.
Upgrade Process - Do Not Uninstall Previous Version
When upgrading to 18.1, install 18.1 directly on top of your currently supported version of Venafi Trust Protection Platform. While Venafi has always recommended this as a best practice, uninstalling the previous version before installing version 18.1 now results in complications to the upgrade process.
Upgrade Process - Windows Authentication to SQL Server
In previous versions of Trust Protection Platform, when using Windows Authentication for communicating with the Venafi MSSQL Server, the Windows user who performed the Trust Protection Platform upgrade was also required to have appropriate permissions for database access. However, in Trust Protection Platform 18.1, this is no longer true. This is because the newly enhanced installation and upgrade process allows database communication to be proxied through the database credentials specified at installation.
Server Agent: Remote Mount Point Scanning
In previous versions of the Server Agent, NFS and CIFS mount points on *NIX operating systems never scanned, even when configured to do so. NFS4 type mount points were always scanned, even when configured not to. In Trust Protection Platform 18.1, all three types now properly honor the agent certificate discovery work configuration as to whether to scan mount points or not. If using Server Agent to do certificate discovery, you should review your work definition while planing your agent and Trust Protection Platform upgrade to 18.1.
NOTE: The Server Agent on Windows still has a known issue where it always scans remote mount points within specific scan directories, even if remote mount points are not configured in the work settings. This will be addressed in a future release.
Server Agent: RPM Files are Now Signed
Starting with Server Agent 18.1, Server Agent RPM files are now signed with an RPM V4 signature. In order to properly validate the RPM files before installation or upgrade, import the Venafi RPM signing key before installation/upgrade. Validation of RPM V4 signatures might fail on versions of RHEL that are earlier than 6.0. In addition, if you customize the RPM, the signature will no longer be valid.
Server Agent: Ignoring files larger than 10000 bytes
When discovering keystores, the Server Agent versions 17.4 and 18.1 are systematically ignoring files that are larger than 10000 bytes. Any certificates contained in such files are no longer discovered.
This issue will be resolved in a future software update. In the meantime, if you need to discover keystores larger than 10000 bytes, we recommend that you not upgrade the Server Agent to either 17.4 or 18.1 until an update has been released.
Oracle Access Manager/SSO Authentication Refactor
Where Trust Protection Platform is configured to authenticate via custom header attributes, Oracle Access Manager integration has been refactored in 17.4 and renamed Pass-through Authentication. If you are integrating with Oracle Access Manager, Siteminder, or any other Single-Sign-On solution that integrates via custom HTTP headers, you will need to update your configuration before the integration will work on 17.4.
For more information, see: Pass-Through Authentication For SSO Updated In 17.4
DigiCert CA Platform Support
The DigiCert integration driver was updated in 17.3 to support CertCentral. It no longer supports the legacy Enterprise platform. If you are currently using the Enterprise platform, please coordinate with DigiCert to migrate to the new CertCentral platform before upgrading to 18.1.
DataPower Integration Support
The DataPower integration driver was updated in 17.3 to support the new REST interface available on newer versions of DataPower. If you are using older versions that support the legacy SSH Command Line Interface (CLI), consider upgrading so that you can take advantage of new functionality in the integration. Legacy versions using SSH CLI are expected to continue to work, but are no longer actively tested.
Venafi License Report
Beginning with Trust Protection Platform 17.3, the Venafi License Report is automatically sent to Venafi. For more information, see Info: License Report Changes FAQ For 17.3
Update to Groups and Work
Beginning with Trust Protection Platform 17.2, the functionality for managing Server Agents, SSH Discovery/Remediation, User Portal, and Enterprise Mobility Agent changed significantly. If you are not yet familiar with these changes, or if you are planning to upgrade to version 17.2 or later, carefully review 17.2 Updates to Groups and Work to learn about the new functionality, why the changes were made, and specific tasks to consider following the upgrade.
SSH Key Internal Storage Migration
When upgrading from Trust Protection Platform 17.1 (or earlier), all SSH keys in the database are migrated to an updated storage format. When Venafi Control Center (VCC) is executed, it might take more time than normal for the migration to complete. In Venafi's internal testing, the migration was able to process approximately 5,800 SSH keys every minute. For 100,000 keys, it might take about 20 minutes to run. The actual processing rate could vary depending upon version of SQL Server you're running, latency between Trust Protection Platform and the database server, database disk speed, CPU/RAM of the SQL Server, and other loads on the server that might be running during the same time period. Progress is displayed in VCC.
During upgrade, you might see the following message in Trust Protection Platform logs:
"SSHManager - Erroneous Key Instance - Key at <path> removed from database because it did not have secret store association. You may need to re-discover this key."
This message indicates that your Trust Protection Platform instance was impacted by the following bug (#33848):
If the same private key was discovered on two devices and the first device was subsequently deleted, the private key was then placed into an orphaned state by TPP and became non-operational.
This bug has been addressed so that the issue will not occur again. The migration script returns the database back to a consistent state by removing the affected private key entries. The affected private keys must then be rediscovered. With agentless discovery, this will happen automatically during the next discovery. With agent-based discovery, you will need to flush the agent’s SSH key cache and re-discover keys on corresponding devices.
Symantec MPKI Enrollment Mode
In previous versions, the certificate that was renewed with the Symantec MPKI driver supported a per-certificate enrollment mode option with which you could control whether your renewal request was treated as a new, renewed, or replacement certificate.
As of Trust Protection Platform 17.2, this feature has been migrated to settings on the Symantec certificate authority (CA) template in the Web Administration Console. Instead of managing the enrollment logic on a certificate-by-certificate basis, the logic is now automatic and configured for all certificates being enrolled via that CA template.
See Configuring the Symantec Managed PKI for SSL CA template 
Oracle Database Server No Longer Supported
WARNING! If your Trust Protection Platform database is currently being hosted on Oracle, do NOT attempt to upgrade to 18.1. You must first migrate your production database from Oracle to Microsoft SQL Server. Contact Venafi Customer Support for assistance with the migration.
Change in Requirements for Database Service Account Permissions
Enhancements made in 15.1, 15.3, 16.2, and 17.1 have changed the permissions required by the Microsoft SQL Service account used to connect Trust Protection Platform to the database. Refer to the sample grant scripts (sample-grants.sql) in the Database Scripts\MSSQL\Grants folder for sample scripts to learn how to modify the permissions for your database.
Consult with your database administrator (DBA) before changing permissions for the database.
DSA SSH Credentials for SSH Connections
Trust Protection Platform 17.2 and 17.1.2 have a new version of Venafi's Maverick library that is used as an SSH client by Trust Protection Platform to communicate with remote systems. If you want to discover DSA keys or use DSA keys for authentication to remote systems, then do the following:
- In the Windows Control Panel, navigate to the Network Connections, Advanced settings. Disable the setting for Federal Information Processing Support (FIPS) compliance for this network.
- On the Trust Protection Platform server running Discovery, add the following registry key: HKLM\Software\Venafi\Platform\EnableSSHDSS (string key), value: 1.
Aperture Certificate Status Updated
The Certificate Inventory Status column is divided into two columns: Risks and Status. The Status column contains a single life-cycle stage, such as "Renewing" or "Pending My Approval". The Risks column can contain one or more tags, such as "Unapproved Issuer" and/or "No Local Dual Control". The Certificate Overview Banner has been updated to show "Status" information only (not Risk). If you have custom reports that were reporting on Status and wish for them to continue to report on certificate risk information, you will need to update the report to include the new column.
Encrypted Connection to Microsoft SQL
Trust Protection Platform can now require a secure, encrypted connection to the database. To enable this option, open Venafi Control Center (VCC) on each Trust Protection Platform server, click Change Database Password, select Encrypt all database communications, and click the Verify button. This security feature requires a valid TLS certificate on the Microsoft SQL Server. You may have to install/replace the certificate on your SQL server prior to enabling this functionality on each Trust Protection Platform server.
See Also: How to enable SSL encryption for an instance of SQL Server by using Microsoft Management Console
Update of Universal C Runtime is Now Required
Starting in version 16.3, Trust Protection Platform requires an update of the Universal C Runtime in Windows in order to provide SNI (Server Name Indication) support for SSL/TLS validation of certificates. This update must be installed before you run the 16.4 Trust Protection Platform (or later) installers. This is required on both Windows 2008 R2 and Windows 2012 R2.
Download the update specific to your OS version at: https://support.microsoft.com/en-us/kb/2999226
Trust Protection Platform 16.4 Requires .NET Framework 4.6.1
Before upgrading to Trust Protection Platform 18.1 from 16.3 (or earlier,) make sure the .NET Framework is updated to 4.6.1.
You can download the offline .NET 4.6.1 installer for Windows 2012 R2 at:
https://www.microsoft.com/en-us/download/details.aspx?id=49982
NOTE: Windows Server 2016 comes pre-installed with .NET 4.6.2
Web Admin Console Policy Tree Performance Improvement
The Policy Tree in the Trust Protection Platform 16.4 Web Administration Console has been refactored to provide significantly faster load times. One behavioral difference to notice is that all nodes of the tree have a plus sign (+) for the expansion of child nodes. This sign is displayed for all objects. If a node does not have any child objects, the + sign disappears after it is clicked.
Privileged Command Set Change for SSH Agentless
In 16.4 the list of commands that the SSH discovery and remediation engine runs with sudo privileges has changed. Some commands are no longer required in order to run as a privileged user and some new commands are required. Refer to this article for detailed instructions on restricting commands in sudoers to only those required for the agentless SSH account.
The following commands are no longer required and can be removed from /etc/sudoers entry:
- find
- sh –c find *
- host
- hostname
- touch
The following new commands need to be present in /etc/sudoers entry:
- grep
- sha256sum
For more information, see: Restricting Account To Use With Agentless SSH
Updated SSH Folder Policy Violation Settings in Aperture
When configuring SSH folder policy violation settings in Aperture, the functionality has been modified for consistency and clarity. For example, in previous versions, one setting was called “Allow Root Access.” This setting has been renamed “Flag Root Access” so it is clear that items will still be permitted, but they will be flagged with a status tag that allows you to find them easily.
If you are upgrading to version 16.3, your folders will be updated automatically. The underlying behavior won’t change. So, if items were being given status messages in older versions, they will continue to be given status messages in 16.3. The labels are now clearer about what is occurring when these settings are being configured.
Password Complexity Requirements are Increased and "on" by Default
In TPP 16.3, password complexity requirements have been updated to meet or exceed industry standards such as SANS, NIST, Microsoft, and PCI-DSS.
The updated requirements are:
- At least 12 characters long
- Must contain a combination of at least three out of the following four categories:
- uppercase alphabetic
- lowercase alphabetic
- numeric, and
- special characters
These changes apply to:
- Downloading certificates that contain private keys from the Web Administration Console or Aperture
- Retrieving certificates that contain private keys from the WebSDK
- New local Trust Protection Platform accounts (or when passwords are changed for existing accounts)
NOTE: The complexity requirements listed above do not apply to the automated installation of certificates via provisioning drivers. These are typically governed by password credential objects via permissions and policy.
As before, Master Admins (or those with appropriate delegated permissions) can turn complexity requirements off for certificate private key download via policy.
MD5 to SHA-256 Host Key Conversion
As part of the SSH-based agentless connections that enable certificate provisioning/validation and SSH key discovery/management, Trust Protection Platform provides the ability to manage and configure trust of SSH host keys. Beginning in 17.1, trusted SSH host keys are stored using SHA-256 instead of MD5. Following an upgrade to 17.1 or later, this change may impact host key trust during the first connection on each device object where you are enforcing host key trust. If you are enforcing host key trust on device objects in Trust Protection Platform for SSH agentless connections, please read the following KB article: MD5 to SHA-256 Host Key Conversion.
Deprecated functionality:
Click here for the latest KB listing deprecated functionality in the current and past versions of Trust Protection Platform.
https://support.venafi.com/hc/en-us/articles/115001578651
Functionality scheduled for deprecation in future releases:
Click here for the latest KB article on features scheduled for deprecation in future releases of Trust Protection Platform.
https://support.venafi.com/hc/en-us/articles/115001662292
Comments