JKS Certificate Management with AppViewX

Introduction

The need to deliver fast IT is more prominent than ever. Each day, teams are tasked with developing new applications to cater to the needs of growing businesses. However, in the name of both time and agility, they are forced to take costly shortcuts, significantly compromising security as they rush to meet deadlines.

X.509 certificates and their keys are critical to application security, but in today’s business environment, busy IT professionals don’t have the bandwidth to manage them efficiently. These particular certificates are essential to properly authenticating the identity of an application and encrypting traffic between endpoints, and they are surging in number as enterprises scale. With multiple certificate authorities (Comodo, GoDaddy), certificate formats (.pem, .jks) and device functionalities (F5, IBM WebSphere) to handle, antiquated management processes simply aren’t enough. Not only are these manual methods error-prone, they also lack the visibility required to flag inconsistencies before it’s too late.

Unfortunately, this is not the only problem. The average IT team is not properly enforcing certificate-level policies and access controls. This means anyone can create SSL certificates in the environment, and in the interest of time, they often go undocumented, posing a huge security risk. No one knows exactly when these undocumented certificates will expire, which ultimately leads to costly application outages.

Without an automated way to deploy, renew and revoke certificates and keys on time, enterprises not only risk damage to their brand’s reputation but also lose critical customer trust.

Simplify Certificate Management with AppViewX

AppViewX’s Certificate Lifecycle Automation solution is a one-stop solution for the automated discovery, expiry alerting, renewal, provisioning and revoking of SSL/TLS certificates. It arms Security Operations and Public Key Infrastructure (PKI) teams with the critical insights they need to avoid outages and other problems caused by non-compliant certificates.

The AppViewX Platform integrates with major certificate authorities like GeoTrust, Comodo, GoDaddy, DigiCert, Microsoft CA and Entrust.

1) Discovery and Inventory

Not only can rogue, unmanaged certificates lead to application outages, they also serve as easy targets for hackers. The Certificate Lifecycle Automation solution helps users guard against these outages and hacks by enabling on-demand certificate discovery across servers, clients, and ADC devices. The user can schedule individual discoveries as-needed, or set them to reoccur each day at midnight. Once discovered, the certificates are automatically converted into an inventory with their keys stored safely. Users can choose between a FIPS-140 compliant, AES 256 encrypted key-store or an industry-standard HSM to store private keys.

Now, let’s consider a scenario where the user needs to discover JKS certificates within a Linux server. Figure 1.1 above illustrates a sample server addition screen. Before starting the discovery process, the user must add the necessary servers to the platform. The device name, IP address, SSH Port and device credentials must also be provided before AppViewX can establish a successful connection with any device. Because .jks certificates are password protected, users must provide the key store password to retrieve certificate-related information from the given location. If the certificates are present in multiple locations within the same server, the user can use the “Add” option to enable discovery from multiple source locations. The “Trust store location” and “Trust store password” options can be used to retrieve the intermediate and root certificates needed to complete the trust chain and, to make it easier, the passwords are automatically stored into a password vault to avoid the hassle of remembering multiple passwords.

Once the user inputs the server details, the user can initiate the discovery process (Figure 1.2). The user selects the necessary devices from the list provided and clicks “discover” to scan the source locations provided under each server. Each certificate is then assigned to a group according to the user-defined policies set during the policy configuration stage. These same steps apply to all supported server and ADC devices, like F5, A10, Citrix, Apache Tomcat, Microsoft IIS and Oracle WebLogic.

Supported Actions	Application Servers	JKS Support
Discovery	IBM WebSphere	Yes
	Oracle WebLogic	Yes
	Apache Tomcat	Yes
	Microsoft Windows	Yes

2) Push and Renew

Each step in the certificate enrollment process introduces the potential for costly human error. With the AppViewX Platform’s automation feature, users work from a single console to order, push, renew, revoke and delete certificates with ease and accuracy.

Now, let’s consider the team needs to push .jks certificates to their Linux servers. First, the user selects the certificate from their inventory. Next, they choose the connector (as seen in Figure 2.1) and choose the destination server from the list of “Available Devices,” which were added in the “Discovery” step. If the user needs to add a new device, they choose the “Add Manually” option (as seen in Fig 1.1).

Once the devices are selected, users designate a password-protected key store location for the new .jks certificate. The pre and post-push scripts help users run custom validations during the push operation. The “Push Automatically” feature allows them to implement the push once the connector is successfully added. Irrespective of the certificate format (.pem, etc), the certificate is automatically converted to .jks once the push is implemented. To avoid expiration, it is important to monitor critical SSL/TLS certificates on a daily or weekly basis after the push (see Figure 2.1).

After a successful push, the certificate-device association is graphically represented as shown in Figure 2.2. If a certificate is expiring soon, users can right-click on the certificate to view a host of possible actions. For example, if the user chooses to “Renew,” a CSR is generated immediately and sent to the CA with a request for a new certificate. Once the CA delivers it, the platform checks the “Push Automatically” tab, which appeared on the previous screen (Figure 2.1). Then, the certificate is automatically converted to .jks before being pushed to the server. Users should note the new content of the .jks file will merge with the existing one if there is no change to either the target location or the file name (provided the password remains the same).

Supported Actions	Application Servers	JKS Support
Push (and Renew)	IBM WebSphere	Yes
	Oracle WebLogic	Yes
	Apache Tomcat	Yes
	Microsoft Windows	Yes

3) Policy and Reports

Weak certificates and unregulated access can compromise the security of an application infrastructure. With the Certificate Lifecycle Automation solution, users can easily administer policies – such as recommended cryptographic techniques, CAs, and workflows – to eliminate rogue certificates. Users can delegate access with an-inbuilt comprehensive role-based access control and apply granular visibility to either individual certificates or entire certificate groups to enable efficient provisioning. The certificates can then be grouped based on functionality or by their underlying policy group

As seen in Figure 3.1, The AppViewX Platform users can limit device-level visibility. They can provide read and write access or read access only based on a colleague’s role. While write access is mandatory for AppViewX to push a certificate onto a device, users can limit the features available to others after the device-level control is complete. For example, administrators can allow other users to view the inventory, but not to upload new certificates to it.

However, this is just half of the delegation functionality. The other half is the requester-approver workflow function, which can be used to set approvers for each workflow to improve process quality and transparency.

To enhance accountability even further, every action is audited giving users superior troubleshooting capability and keeping them compliant all at the same time.

Manually tracking certificates is a time-intensive, error-prone undertaking that exposes growing enterprises to increased security risk and untimely outages. That’s why IT teams must invest in tools like AppViewX that make it virtually impossible to miss an expiration date

And, apart from just monitoring for expiry, AppViewX prevents weak, deprecated certificates from entering the system and posing a significant threat to an enterprise’s security. By running key compliance reports (as seen in Figure 3.2) users have the visibility needed to proactively remove threatening certificates from their ecosystems.

Conclusion

Given PKI technology is secure, the need for digital certificates in secure communications and authentications is only going to increase. As a result, enterprises will need more certificates in more formats from multiple authorities to push to multiple devices with varying functionalities. To put it quite simply, using manual methods will not get the job done. Users must adopt specialized tools like AppViewX’s Certificate Lifecycle Automation solution to help manage and automate the entire certificate lifecycle, extinguishing threats before it’s too late.