This extraordinary guideline was written in collaboration with Digicert, Venafi, Thales, F5, MITRE, Symantec. All of them well known technology and security companies around the world.
The document has 4 different parts:
An Executive Summary
Security Risks and Recommended Best Practices
Approach, Architecture and Security Characteristics
This is a must for the administration of large-scale TLS server certificates, how to establish a formal TLS certificate management program and it also enumerates all elements that should be considered for inclusion in such a program.
It addresses some specific challenges like: The automatic renewal of digital certificates in production environments, working with DevOps and TLS certificates, implementing an architecture to be protected of attacks hidden in TLS connection tunnels, recommendations for key-lenght, signing algorithms, validity periods in digital certificates, recommendation for crypto-agility (a very popular topic in cryptography these days) and much more.
You can download the complete document directly from its site:
Recently I have been testing this tool when I work with Java Key Stores or Trust Stores. It’s KeyStore Explorer.
You can always use command line to execute cryptographic tasks in java using keytool library or bouncy castle, however for many daily activities like generating CSR files, creating cryptographic keys or managing several keystores or trust stores, you prefer a more friendly tool. This is where KeyStore Explorer fits in.
It’s support for cryptographic tasks, according to it’s website, is:
And you can handle, compare and manage many keystore files from the main window and explore their content easily:
There are many new technologies, controls, mechanisms, modules, libraries for protecting and securing assets and information. Usually these new technologies were created and developed by people with good skills in the field, however, one of the main problems is the implementation phase.
Believe it or not, most of the vulnerabilities, either published or zero-day, exist because of a bad or terrible implementation of something that is secure in escense.
Think about cryptography. In general, cryptographic standard algorithms are approved and validated by many cryptographers around the world but when it comes the implementation phase, the standard or algorithm is implemented by a group of peole working at the same company or sometimes by only one developer with limited training in security and/or cryptography.
One of these examples is WEP Security Protocol for Wireless communications. It has different vulnerabilities but particularly the vulnerability of the key stream is a consequence of a weakness in the implementation of the RC4 stream cipher, not the RC4 algorithm by itself.