Jon and Chris,
> Am 11.08.2022 um 19:33 schrieb Christopher Schultz > <ch...@christopherschultz.net>: > > Jon, > >> On 8/11/22 12:53, jonmcalexan...@wellsfargo.com.INVALID wrote: >> I was just wondering if there was a vanity name for the "new" structure is >> all, to differentiate in documentation. > > *shrug* > > "New"? > > That kind of loses its lustre after a while. Today, that's just "the way you > do it". So the "new" way is The Way and the old way is ... the Old Way. > > Use SSLHostConfig. I'm sure you'll sleep better at night after you've > switched. > > -chris > >>> -----Original Message----- >>> From: Christopher Schultz <ch...@christopherschultz.net> >>> Sent: Thursday, August 11, 2022 11:29 AM >>> To: users@tomcat.apache.org >>> Subject: Re: Simple SSL question >>> >>> Jon, >>> >>> On 8/11/22 11:22, jonmcalexan...@wellsfargo.com.INVALID wrote: >>>> Is there a "name" for the new connector style? The old is known as the >>>> Coyote Connector. >>> Coyote is just the name of the connector itself, for whatever reason. >>> Both the new and old-style configuration is using the same connector >>> underneath. When you configure everything on the <Connector>, Tomcat >>> still creates an SSLHostConfig object under the covers and fills it with >>> that >>> same data. >>> >>> Why should you bother migrating? Two reasons: >>> >>> 1. The new configuration is easier to read IMO. It separates the TLS >>> host/key/certificate and all that associated stuff from the more basic >>> socket- >>> type stuff for the <Connector> >>> >>> 2. It allows for more options such as proper name-based virtual-hosting with >>> TLS. It also allows multiple types of keys and certificates to be used. For >>> example, you can configure both RSA and EC certificates for a single host. >>> That's just not possible with the one-attribute-to-rule-them-all >>> configuration >>> where everything is on the <Connector> element. >>> I have tried all the fancy new cert options and they are cool. And I do agree that it's more readable. What would be useful would be one sample how to transfer a simple "old" config to SSLHostConfig. That would take away the fear to get going. In another thread I said, that it may be a lot of work to migrate a lot of tomcat instances. But I guess most people would only need a single SSLHostConfig to add to their one connector... Peter >>> -chris >>> >>>>> -----Original Message----- >>>>> From: Mark Thomas <ma...@apache.org> >>>>> Sent: Wednesday, August 10, 2022 2:43 PM >>>>> To: users@tomcat.apache.org >>>>> Subject: Re: Simple SSL question >>>>> >>>>> On 10/08/2022 19:22, jonmcalexan...@wellsfargo.com.INVALID wrote: >>>>>> Ok, I'm asking a rather simple, stupid (in my opinion) question, but >>>>>> here >>>>> goes: >>>>>> >>>>>> What is the best practice form of connector for SSL. Is it the >>>>>> old-school >>>>> coyote connector or the connector with the <SSLHostConfig...> section? >>>>> >>>>> <SSLHostConfig...> >>>>> >>>>> The old style isn't supported in Tomcat 10.0.x onwards. >>>>> >>>>>> Are the two interchangeable, or does the SSLHostConfig one rely on >>>>> openssl and won't work without it? The documentation is confusing me >>>>> on a hump day afternoon. >>>>> >>>>> They are interchangeable. However, if you want to configure TLS >>>>> virtual hosting with SNI you'll need to use SSLHostConfig. >>>>> >>>>> Both approaches can be used with JSSE and OpenSSL based TLS >>>>> implementations. >>>>> >>>>> Mark >>>>> >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Dream * Excel * Explore * Inspire >>>>>> Jon McAlexander >>>>>> Senior Infrastructure Engineer >>>>>> Asst. Vice President >>>>>> He/His >>>>>> >>>>>> Middleware Product Engineering >>>>>> Enterprise CIO | EAS | Middleware | Infrastructure Solutions >>>>>> >>>>>> 8080 Cobblestone Rd | Urbandale, IA 50322 >>>>>> MAC: F4469-010 >>>>>> Tel 515-988-2508 | Cell 515-988-2508 >>>>>> >>>>>> >>>>> >>> jonmcalexan...@wellsfargo.com<mailto:jonmcalexan...@wellsfargo.com> >>>>>> This message may contain confidential and/or privileged information. >>>>>> If you >>>>> are not the addressee or authorized to receive this for the >>>>> addressee, you must not use, copy, disclose, or take any action based >>>>> on this message or any information herein. If you have received this >>>>> message in error, please advise the sender immediately by reply >>>>> e-mail and delete this message. Thank you for your cooperation. >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
