- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Tue, 22 Sep 2015 18:10:34 -0400
- To: public-webid@w3.org
- Message-ID: <5601D1DA.9020909@openlinksw.com>
On 9/22/15 5:43 PM, Melvin Carvalho wrote: > http://techblog.netflix.com/2015/09/introducing-lemur.html > > > Introducing Lemur > > by: Kevin Glisson <https://twitter.com/kevgliss>, Jason Chan > <https://twitter.com/chanjbs> and Ben Hagen <https://twitter.com/benhagen> > Netflix is pleased to announce the open source release of our x.509 > certificate orchestration framework : Lemur! > *The Challenge of Certificate Management * > Public Key Infrastructure > <https://en.wikipedia.org/wiki/Public_key_infrastructure>is a set of > hardware, software, people, policies, and procedures needed to create, > manage, distribute, use, store, and revoke digital certificates and > manage public-key encryption. PKI allows for secure communication by > establishing chains of trust between two entities. > * > * > There are three main components to PKI that we are attempting to address: > > 1. > > > Public Certificate- A cryptographic document that proves the > ownership of a public key, which can be used for signing, proving > identity or encrypting data. > 2. > Private Key- A cryptographic document that is used to decrypt data > encrypted by a public key. > 3. > Certificate Authorities (CAs)- Third-party or internal services > that validate those they do business with. They provide > confirmation that a client is talking to the server it thinks it > is. Their public certificates are loaded into major operating > systems and provide a basis of trust for others to build on. > > * > * > The management of all the pieces needed for PKI can be a confusing and > painful experience. Certificates have expiration dates - if they are > allowed to expire without replacing communication can be interrupted, > impacting a system’s availability. And, private keys must never be > exposed to any untrusted entities - any loss of a private key can > impact the confidentiality of communications. There is also increased > complexity when creating certificates that support a diverse pool of > browsers and devices. It is non-trivial to track which devices and > browsers trust which certificate authorities. > * > * > On top of the management of these sensitive and important pieces of > information, the tools used to create manage and interact with PKI > have confusing or ambiguous options. This lack of usability can lead > to mistakes and undermine the security of PKI. > * > * > For non-experts the experience of creating certificates can be an > intimidating one. > * > * > > > Empowering the Developer > > At Netflix developers are responsible for their entire application > environment, and we are moving to an environment that requires the use > of HTTPS for all web applications. This means developers often have to > go through the process of certificate procurement and deployment for > their services. Let’s take a look at what a typical procurement > process might look like: > Here we see an example workflow that a developer might take when > creating a new service that has TLS enabled. > * > * > <https://lh6.googleusercontent.com/MX5e5ySuiiaFrhwFy0J2b2ZcCyS-2QYVY02iBCC1JNDT9OjXx_bI85dOCzLFdJDL6dpPcib1AUTVmjNSKl6OZkyUB3IOtV8wMRN_p-6kqjkxTL5TVFuTcHWh8i0dgbb8PbEdg7Y>There > are quite a few steps to this process and much of it is typically > handled by humans. Let’s enumerate them: > > 1. > Create Certificate Signing Request (CSR)- A CSR is a > cryptographically signed request that has information such as > State/Province, Location, Organization Name and other details > about the entity requesting the certificate and what the > certificate is for. Creating a CSR typically requires the > developer to use OpenSSL commands to generate a private key and > enter the correct information. The OpenSSL command line contains > hundreds of options and significant flexibility. This flexibility > can often intimidate developers or cause them to make mistakes > that undermine the security of the certificate. > > * > * > > 2. > Submit CSR- The developer then submits the CSR to a CA. Where to > submit the CSR can be confusing. Most organizations have internal > and external CAs. Internal CAs are used for inter-service or > inter-node communication anywhere you have control of both sides > of transmission and can thus control who to trust. External CAs > are typically used when you don’t have control of both sides of a > transmission. Think about your browser communicating with a > banking website over HTTPS. It relies on the trust built by third > parties (Symantec/Digicert, GeoTrust etc.) in order to ensure that > we are talking to who we think we are. External CAs are used for > the vast majority of Internet-facing websites. > > * > * > > 3. > Approve CSR- Due to the sensitive and error-prone nature of the > certificate request process, the choice is often made to inject an > approval process into the workflow. In this case, a security > engineer would review that a request is valid and correct before > issuing the certificate. > > * > * > > 4. > Deploy Certificate- Eventually the issued certificate needs to be > placed on a server that will handle the request. It’s now up to > the developer to ensure that the keys and server certificates are > correctly placed and configured on the server and that the keys > are kept in a safe location. > > * > * > > 5. > Store Secrets- An optional, but important step is to ensure that > secrets can be retrieved at a later date. If a server ever needs > to be re-deployed these keys will be needed in order to re-use the > issued certificate. > > * > * > Each of these steps have the developer moving through various systems > and interfaces, potentially copying and pasting sensitive key material > from one system to another. This kind of information spread can lead > to situations where a developer might not correctly clean up the > private keys they have generated or accidently expose the information, > which could put their whole service at risk. Ideally a developer would > never have to handle key material at all. > * > * > > > Toward Better Certificate Management > > Certificate management is not a new challenge, tools like EJBCA > <http://www.ejbca.org/>, OpenCA <http://www.openca.org/>, and more > recently Let’s Encrypt <https://letsencrypt.org/>are all helping to > make certificate management easier. When setting out to make > certificate management better we had two main goals: First, increase > the usability and convenience of procuring a certificate in such a way > that would not be intimidating to users. Second, harden the > procurement process by generating high strength keys and handling them > with care. > * > * > Meet Lemur! > * > * > > > Lemur > > Lemur is a certificate management framework that acts as a broker > between certificate authorities and internal deployment and management > tools. This allows us to build in defaults and templates for the most > common use cases, reduce the need for a developer to be exposed to > sensitive key material, and provides a centralized location from which > to manage and monitor all aspects of the certificate lifecycle. > * > * > We will use the following terminology throughout the rest of the > discussion: > * > * > > * > Issuers are internal or third-party certificate authorities > * > Destinations are deployment targets, for TLS these would be the > servers terminating web requests. > * > Sourcesare any certificate store, these can include third party > sources such as AWS, GAE, even source code. > * > Notificationsare ways for a subscriber to be notified about a > change with their certificate. > > * > * > Unlike many of our tools Lemur is not tightly bound to AWS, in fact > Lemur provides several different integration points that allows it to > fit into just about any existing environment. > * > * > Security engineers can leverage Lemur to act as a broker between > deployment systems and certificate authorities. It provides a unified > view of, and tracks all certificates in an environment regardless of > where they were issued. > * > * > Let’s take a look at what a developer's new workflow would look like > using Lemur: > > <http://1.bp.blogspot.com/-ddSboGM8cbI/VgBSAucAoQI/AAAAAAAABQE/PZJdwxtbOrU/s1600/new.png> > * > * > Some key benefits of the new workflow are: > > * > Developer no longer needs to know OpenSSL commands > * > Developer no longer needs to know how to safely handle sensitive > key material > * > Certificate is immediately deployed and usable > * > Keys are generated with known strength properties > * > Centralized tracking and notification > * > Common API for internal users > > * > * > This interface is much more forgiving than that of a command line and > allows for helpful suggestions and input validation. > For advanced users, Lemur supports all certificate options that the > target issuer supports. > ** > Lemur’s destination plugins allow for a developer to pick an > environment to upload a certificate. Having Lemur handle the > propagation of sensitive material keeps it off developer’s laptops and > ensures secure transmission. Out of the box Lemur supports > multi-account AWS deployments. Over time, we hope that others can use > the common plugin interface to fit their specific needs. > ** > Even with all the things that Lemur does for us we knew there would > use cases where certificates are not issued through Lemur. For > example, a third party hosting and maintaining a marketing site, or a > payment provider generating certificates for secure communication with > their service. > ** > To help with these use cases and provide the best possible visibility > into an organization’s certificate deployment, Lemur has the concept > of source plugins and the ability to import certificates. Source > plugins allow Lemur to reach out into different environments and > discover and catalog existing certificates, making them an easy way to > bootstrap Lemur’s certificate management within an organization. > Lemur creates, discovers and deploys certificates. It also securely > stores the sensitive key material created during the procurement > process. Letting Lemur handle key management provides a centralized > and known method of encryption and the ability to audit the key’s > usage and access. > ** > > > Architecture > > Lemur makes use of the following components : > > * > Python 2.7, 3.4 with Flask API (including a number of helper packages) > * > AngularJS UI > * > Postgres > * > Optional use of AWS Simple Email Service (SES) for email notifications > > We’re shipping Lemur with built-in plugins for that allow you to issue > certificates from Verisign/Symantec and allow for the discovery and > deployment of certificates into AWS. > ** > > > Getting Started > > Lemur is available now on theNetflix Open Source site > <https://github.com/Netflix/lemur>. You can try out Lemur usingDocker > <https://github.com/Netflix/lemur-docker>. Detailed instructions on > setup and configuration are available in our docs > <http://lemur.readthedocs.org/>. > ** > > > Interested in Contributing? > > Feel free to reach out or submit pull requests if you have any > suggestions. We’re looking forward to seeing what new plugins you > create to to make Lemur your own! We hope you’ll find Lemur as useful > as we do! > ** > > > Conclusion > > Lemur is helping the Netflix security team manage our PKI > infrastructure by empowering developers and creating a paved road to > SSL/TLS enabled applications. Lemur is available on ourGitHub > <http://netflix.github.io/#repo>site now! SeeAlso: http://docs.aws.amazon.com/apigateway/latest/developerguide/getting-started-client-side-ssl-authentication.html#generate-client-certificate In all cases, the ability to place an HTTP URI in SAN is what's critical to WebID-TLS protocol. -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Tuesday, 22 September 2015 22:11:02 UTC