Re: Trying to understand How Tomcat uses Keystore for SSL
Thanks Chuck In plain text Please comment on the following write-up. Setting Up SSL for TomCat 1) Overview of Security for Tomcat Security is hard, which by extension means setting up SSL is hard. One of the things that make this difficult is that there are multiple layers of specifications. In this explanation we are only go as deep into the technical description as is necessary for you to understand what is going on. At the bottom layer of security is cryptography, which is based on encryption. We won’t go into encryption except to say that all encryption protocols are breakable, except the One Time Pad, which is impracticable. The principal of computer security is to make it very difficult to break the encryption. Using a modern desktop computer it would take a little over 6.4 quadrillion years to crack the encryption of a 2048 bit RSA certificate. Note: practical quantum computers large enough to negate this time estimate don't exist, yet There are two encryption schemes that are of interest, asymmetric and symmetric encryption. Asymmetric encryption uses a public and a private encryption key. The public key, which as its name states, is public, i.e. it is available to all. The private key is and must be closely guarded. A message encrypted with the private key can be decrypted by the public key and vis-a-versa. SSL or Secure Sockets Layer, is the high level security layer that we are attempting to implement for for our implementation of Tomcat. SSL uses both asymmetric and symmetric encryption, but at the level we are interested in we only deal with the former, while Tomcat and the other parties like the browser deal with both. In the scenario that we are addressing there are three parties involved * your installation of Tomcat * the browser with whom you wish to communicate and * the Certificate Authority or CA, e.g. letsencrypt, Comodo, etc. In cryptography, a certificate authority or certification authority (CA) is an entity that issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others (relying parties) to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. A CA acts as a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate. The format of these certificates is specified by the X.509 standard. In order to set up SSL, you want to get a private/public key pair and what is called a Security Certificate or more properly, an X509 certificate. The Security Certificate contains information about who you are and is attested to by the CA, whom the browser trusts. In some cases, like the CA letsencrypt, the trust of the CA by all browser is not yet there, so the certificate contains an intermediate CA whom the browsers trust and who attests for the CA who trusts your domain. Each of the CA's, the root CA, who trusts us and intermediate who trusts the root CA, digitally sign (another specification) the certificate with their private keys, so that the browsers and other interested parties can verify the subject of the certificate. This is accomplished by using the CA's public key to assure that this certificate was signed by the root or intermediate CA with their private key. The certificates and keys have specified binary structures so that they can be machine read. This structure is defined by using an abstract notation called ASN.1, Abstract Syntax Notation One, which defines data types in a binary format. A subset of ASN.1, BER defines how to encode each value type. BER has more than one way to encode a data type, so there is DER, which gives a unique encoding to each of the BER data types. A DER encoded certificate is an encoded binary form of the certificate. Binary data can not be sent over the internet, so for transportation they are base64 encoded, which transforms the binary bits into ASCII, which can then be sent over the internet. Note base64 is not human readable but is NOT encryption. Encoding and decoding can be done using a well known algorithm. In essence PEM files are just base64 encoded versions of the DER encoded data. Before we leave this section there is another distinction. We use the term SSL, Secure Sockets Layer. SSL has been replaced by TLS, Transport Layer Security. TLS is more secure than SSL, which is affectedly dead. The bad guys are continually working to break security, whereas the good guys are working to beat the bad guys. Consequently, for a secure system you must continually upgrade to the latest security protocols. 2) How to Create and See what You Have There is an open source set of commands called openssl which will allow you to look inside the various certificates and keys that you have as well as other functionality. You can download openssl at https://www.openssl.org/source/ . Openssl comes as a set of command
RE: Trying to understand How Tomcat uses Keystore for SSL
> From: Don Flinn [mailto:fl...@alum.mit.edu] > Subject: Re: Trying to understand How Tomcat uses Keystore for SSL > Attached is a first cut at setting up SSL for Tomcat. It is in MicroSoft Word. Most attachments are automatically stripped by the mailing list server. You can either send it in plain text or post it somewhere publicly accessible. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. smime.p7s Description: S/MIME cryptographic signature
Re: Trying to understand How Tomcat uses Keystore for SSL
Chris, Attached is a first cut at setting up SSL for Tomcat. It is in MicroSoft Word. Hopefully people have that. If not I'll send it in another format that is acceptable. I tried to achieve a balance between completeness and brevity by only going deep enough to give the reader enough information to understand what is needed to use SSL/TLS with Tomcat. When it got down to keystore I effectively just repeated what was on the Tomcat SSL website. A weak point in the writeup (among many others) is getting Tomcat to listen on port 80 for letsencrpy. If this might be useful please comment and correct. Don On Fri, Dec 1, 2017 at 11:32 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Don, > > On 12/1/17 3:14 AM, Don Flinn wrote: > > I'll be happy to accept your challenge to try to write some > > documentation for the site from a newbee's point of view. It will > > be on the slow side as my 'day job' will interfere somewhat. It > > also will require some correction of errors. > > No problem at all. Just reach-out to the group if you need any > hand-holding. > > - -chris > > On Wed, Nov 29, 2017 at 9:37 AM, Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > > Don, > > > > On 11/28/17 4:55 PM, Don Flinn wrote: > >> In fact, I think you are using PEM-encoded DER files and > >> not a packaged keystore, even though your > >> SSLHostConfig's keystoreType is set to "PKCS12". > > Yes, I am using PEM files. Got to read more on DER files. > > > > PEM is an encoding, while DER is really the file format. It's like > > saying "is this file text/plain or UTF-8?" > > > > This is a great read for almost anyone who cares about x509 > > certificates : > > > > https://support.ssl.com/Knowledgebase/Article/View/19/0/der-vs-crt-vs- > ce > > > > > r-vs-pem-certificates-and-how-to-convert-them > > > So do I just drop the keystoreType="PKCS12" from the > connector? > > Theoretically, yes. The keystoreType is only used when there is a > > keystore and not "certificate files", etc. > > > > If there's anything inaccurate on the Tomcat site > > No, I was talking about other sites, not the Tomcat site. > I've been reading all over the internet for that which seems > related. My statement was a caution to not believe everything > you read. 'Trust but verify' > > > > Mark has given a number of presentations on TLS and they are very > > accessible. Have a look at the slides (and some audio/video) on > > the "presentations" page on the Tomcat site. Each of them has a > > varying level of "introductoryness", but I think the more recent > > ones like "Introduction to Tomcat and TLS" from TomcatCon in Miami > > are probably the best ones to see for beginners. > > > Your e-mail has been very helpful, not only to me, but I > believe to others. With respect to the Tomcat site, I think > a lot of what you wrote would be very helpful there. For > example, the Tomcat write up on SSL describes how to do self > signed certificates and fleetingly mentions that if you have > a certificate from a CA that you could use e.g. openssl and > then refers the reader to their java documentation and > openssl documentation. Not too helpful to the > security/Tomcat novice. > > > > Agreed. Would you care to write some new documentation and/or > > prepare a patch for the site? IT's usually best when beginners > > write for their own audience. I, for example, understand it > > backwards and forwards so when I write I have a skewed perspective. > > Writing as a beginner can re-focus the narrative for a different > > audience. > > > > If you need any help grabbing the site from svn, etc. please just > > ask. > > > Thanks for your patience and help. > > > > You are more important than the software. No, really: > > https://blogs.apache.org/foundation/entry/asf_15_community_over_code > > > > -chris > >> > >> - > >> > >> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlohhBIdHGNocmlzQGNo > cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjrXxAApjseUCOZqro7Hutg > qXYaLdy6KD4ws4A5abYWnCMHvgO2oJxfxXAxnM5YNDgVgPR3r579ZF/zjLBsdYbx > kANY/4bMNse3LkJCkrwy1PclAyWDAMHVLIcc4iKEHL0dsCyGp7qIXHfx4eKv3Jnb > h4wsaoCi7QVk2TUOecOKKEiWRQ2tV1B6W4pAhCACAd0OSG/vYqdxVP2xzPE4AFe9 > vaIi5VwHNU+o/yYMhc5Qy5b+rHs7d1xNS0hr1jiJ4amzNfKUaUTjVAl1U9u9mZb7 > FI3sOIuEvtmXoBEfjWgohFC9XW2lS/EiQKptPT0HzLPUDfNXWi9QD9Ii1OI3sTMH > mw57kST/uz68S4MEiP4os/Cr4O0gnXSzc2uHQQHdqvsOBHbNnBAO9doL07lLzc8B > nktNwbl7G4aAp463gL6H8wk+pRQTUXTnm/oxTtROTF/TYaoYTpcsLdBB0PvMFV0N >
