Re: [jdev] virtual hosting and certificate checking
On Friday 03 March 2006 23:10, Richard Dobson wrote: > > Funnily enough, if we'd had naming in TLS from the start, there probably > > wouldn't even *be* STARTTLS since everyone would be using the better > > method. :-) > > I doubt that since the main reason STARTTLS is there is so that you can > reuse the same port for both encrypted and unencrypted versions of a > protocol not really so you can pass the desired hostname, thats just a > side benefit of being able to start out unencrypted. But wouldn't it then be easier to endorse using _only_ the encrypted version? TX -- Email: [EMAIL PROTECTED] Jabber ID: [EMAIL PROTECTED] Web site: http://trypticon.org/ GPG Fingerprint: 9EEB 97D7 8F7B 7977 F39F A62C B8C7 BC8B 037E EA73 pgpmCBwq4QGzY.pgp Description: PGP signature
Re: [jdev] virtual hosting and certificate checking
Funnily enough, if we'd had naming in TLS from the start, there probably wouldn't even *be* STARTTLS since everyone would be using the better method. :-) I doubt that since the main reason STARTTLS is there is so that you can reuse the same port for both encrypted and unencrypted versions of a protocol not really so you can pass the desired hostname, thats just a side benefit of being able to start out unencrypted. Richard
Re: [jdev] virtual hosting and certificate checking
On Friday 03 March 2006 21:10, Justin Karneges wrote: > Hmm, there shouldn't be a need to introduce server names into TLS, which is > technically supposed to exist independently of TCP/IP. > > IMO, a better way would be to use RFC 2817, which allows upgrading a > plaintext HTTP connection to TLS dynamically. It works essentially the > same way as XMPP's "starttls". Sadly, no one actually uses this great > spec. I'm sure that some services still have a name outside of TCP/IP. Besides, it's only an extension, which does make a bit of sense since you would just choose not to use that extension in the case where you're not going over TCP/IP (analogous to an XMPP server choosing not to allow external auth if the connection is not going over TLS.) Funnily enough, if we'd had naming in TLS from the start, there probably wouldn't even *be* STARTTLS since everyone would be using the better method. :-) RFC 2817 is still neat though. Funny how web browsers, despite being the most used Internet app around, or so they say, are so slow to follow standards. We should have SRV for web browsers too, but hardly anyone implemented that too. TX -- Email: [EMAIL PROTECTED] Jabber ID: [EMAIL PROTECTED] Web site: http://trypticon.org/ GPG Fingerprint: 9EEB 97D7 8F7B 7977 F39F A62C B8C7 BC8B 037E EA73 pgpTrwM2LrARY.pgp Description: PGP signature
Re: [jdev] virtual hosting and certificate checking
On Fri, 3 Mar 2006, Justin Karneges wrote: > > IMO, a better way would be to use RFC 2817, which allows upgrading a plaintext > HTTP connection to TLS dynamically. It works essentially the same way as > XMPP's "starttls". Sadly, no one actually uses this great spec. I get the impression that that is because it's a pain to implement :-) e.g. http://coders.meta.net.nz/weblog/2005/03/25/server-name-indication-or-how-to-virtual-host-ssl/ I note that other protocols which have a starttls function - SMTP, IMAP, POP - don't have a mechanism outside TLS for indicating the server name. XMPP is unusual in this respect. RFC 3546 SNI has the advantage that it solves the problem for all protocols that use TLS, and in the context of HTTP it has MUCH lower latency than RFC 2817. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ HUMBER: WEST OR NORTHWEST 3 OR 4 INCREASING 5 OR 6. WINTRY SHOWERS. MAINLY GOOD.
Re: [jdev] virtual hosting and certificate checking
On Friday 03 March 2006 01:41, Tony Finch wrote: > On Fri, 3 Mar 2006, Jesus Cea wrote: > > In current TLS, client gives the host it is trying to connect, BEFORE > > negociating crypto. So if you are using a modern webserver and a modern > > browser, you can share the IP. > > > > I just don't remember if this feature is present in TLS 1.0 or in the > > current draft for next revision. > > This is an RFC 3546 extension to TLS 1.0 - the "server name indication". > It appears that this is not supported by OpenSSL but it is by GnuTLS. > "Modern browser" in this situation means released within the last few > months. Hmm, there shouldn't be a need to introduce server names into TLS, which is technically supposed to exist independently of TCP/IP. IMO, a better way would be to use RFC 2817, which allows upgrading a plaintext HTTP connection to TLS dynamically. It works essentially the same way as XMPP's "starttls". Sadly, no one actually uses this great spec. -Justin
Re: [jdev] virtual hosting and certificate checking
On Fri, 3 Mar 2006, Jesus Cea wrote: > > In current TLS, client gives the host it is trying to connect, BEFORE > negociating crypto. So if you are using a modern webserver and a modern > browser, you can share the IP. > > I just don't remember if this feature is present in TLS 1.0 or in the > current draft for next revision. This is an RFC 3546 extension to TLS 1.0 - the "server name indication". It appears that this is not supported by OpenSSL but it is by GnuTLS. "Modern browser" in this situation means released within the last few months. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ RATTRAY HEAD TO BERWICK ON TWEED: CYCLONIC 3 OR 4, OCCASIONALLY 5, BECOMING NORTH OR NORTHWEST 5 OR 6 DURING THIS EVENING AND OVERNIGHT. SCATTERED SNOW SHOWERS. GOOD FALLING POOR IN SHOWERS. MODERATE OR ROUGH.
Re: [jdev] virtual hosting and certificate checking
On 3/3/06, Hal Rottenberg <[EMAIL PROTECTED]> wrote: > On 3/2/06, Trejkaz <[EMAIL PROTECTED]> wrote: > > Jesus Cea wrote: > > > In current TLS, client gives the host it is trying to connect, BEFORE > > > negociating crypto. So if you are using a modern webserver and a modern > > > browser, you can share the IP. > > Now, that's awesome. However, I know for sure that the very latest > > release of Apache can't do it, so... > I do it right now on an older version. I asked Google briefly but couldn't find anything. Can you post a link to a HOWTO? -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
Re: [jdev] virtual hosting and certificate checking
On 3/2/06, Trejkaz <[EMAIL PROTECTED]> wrote: > Jesus Cea wrote: > > In current TLS, client gives the host it is trying to connect, BEFORE > > negociating crypto. So if you are using a modern webserver and a modern > > browser, you can share the IP. > > Now, that's awesome. However, I know for sure that the very latest > release of Apache can't do it, so... I do it right now on an older version. -- Psi webmaster (http://psi-im.org) im:[EMAIL PROTECTED] http://halr9000.com
Re: [jdev] virtual hosting and certificate checking
Jesus Cea wrote: In current TLS, client gives the host it is trying to connect, BEFORE negociating crypto. So if you are using a modern webserver and a modern browser, you can share the IP. Now, that's awesome. However, I know for sure that the very latest release of Apache can't do it, so... I just don't remember if this feature is present in TLS 1.0 or in the current draft for next revision. ... it must be in the next revision. TX
Re: [jdev] virtual hosting and certificate checking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Norman Rasmussen wrote: > Don't forget option #3: > > Just like HTTPS, each hostname/certificate has to have it's own IP > address - this is so that we can tell which certificate to present > based on the IP the client has just connected to. In current TLS, client gives the host it is trying to connect, BEFORE negociating crypto. So if you are using a modern webserver and a modern browser, you can share the IP. I just don't remember if this feature is present in TLS 1.0 or in the current draft for next revision. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] http://www.argo.es/~jcea/ _/_/_/_/ _/_/_/_/ _/_/ _/_/_/_/ _/_/_/_/_/ PGP Key Available at KeyServ _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRAd6X5lgi5GaxT1NAQJc2QQAlsXsEUB4jxqUW7/A1MCKUdeR/g+hkl7f WKgxNyoZ1gmMuJHlUfbFX/J9LV7H9807KgewnkjQT30YLj1NIitsMI1hXw/+QsuN hADOfPTd8Y1aRlSDNRglJ4QEgWAd9Mrcag1C/OACTxCpK1OL4pvQNM7zWfCRWxVM 45Mygv3h/ZA= =kUYw -END PGP SIGNATURE-
Re: [jdev] virtual hosting and certificate checking
On Wednesday 01 March 2006 15:49, Peter Saint-Andre wrote: > Yes, CAcert is great and I've been working with them to get support for > id-on-xmppAddr into their certs. But that doesn't necessarily make it > easier for people who are hosting a *lot* of XMPP domains to support TLS. SSL/TLS is supposed to be end-to-end, in the sense that the client and server are the ends. Even if two domains are hosted at the same hosting service, I would definitely not condone sharing of the private key unless the domains are intimately related (e.g., they are owned by the same customer account). -Justin
RE: [jdev] virtual hosting and certificate checking
> Well, but we want people to use TLS. If it's too difficult, then we'll > have a less secure network. And that seems like a Bad Thing even if it's > not our fault. DNS is a much bigger hurdle to XMPP virtual hosting and adoption than certificates. People are already used to installing/purchasing certificates for HTTP, SMTP, IMAP, etc and self signed or cacert certs may suffice. However, most don't have a clue what a SRV record is. When you also host someone's DNS, automating this is simple, but when you don't, it gets very complicated. Most ASP's don't even support SRV. I'd say tied with DNS is education -- hopefully GTalk will help with this. People (even most geeks I talk to) have the idea that IM is either this magical service like AIM or a closed system they can run where they can't talk to anyone but those in their company. The whole cross-domain secure IM concept still hasn't quite sunk in. At least, that's my experience after talking with many, many people outside of our microscopic (perhaps nano-sized, even) XMPP geek circle. Much education, aka marketing, is needed. -JD Conley
Re: [jdev] virtual hosting and certificate checking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Trejkaz wrote: > Gary Burd wrote: >> A couple of snips from the conversation: >> >>> For hosting providers it's usually an up-sell to your >>> customers to add security >> >>> because it's each domain owner's responsibility to >>> manage their own certificate. >> >> Extra cost and responsiblity can impede XMPP adoption. > > Look, if people don't want TLS, we're not forcing them to use it. Well, but we want people to use TLS. If it's too difficult, then we'll have a less secure network. And that seems like a Bad Thing even if it's not our fault. > There are other ways to streamline these things, such as making it > easier for people running an XMPP server to get a certificate. > > As far as "cost", http://www.cacert.org/ -- use it, love it, urge > everyone to add their root certificate. Yes, CAcert is great and I've been working with them to get support for id-on-xmppAddr into their certs. But that doesn't necessarily make it easier for people who are hosting a *lot* of XMPP domains to support TLS. Peter - -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEBjMfNF1RSzyt3NURArkfAJ4nBianzS/6O8hMqAO6hWQxfbg0ugCghJEo i9QdOduxMWNmN0cJwNogV4Y= =jWZG -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature
Re: [jdev] virtual hosting and certificate checking
Gary Burd wrote: A couple of snips from the conversation: For hosting providers it's usually an up-sell to your customers to add security because it's each domain owner's responsibility to manage their own certificate. Extra cost and responsiblity can impede XMPP adoption. Look, if people don't want TLS, we're not forcing them to use it. And it's not XMPP's fault that getting a TLS certificate involves such bureaucracy (I blame Verisign for that, really.) There are other ways to streamline these things, such as making it easier for people running an XMPP server to get a certificate. As far as "cost", http://www.cacert.org/ -- use it, love it, urge everyone to add their root certificate. TX
Re: [jdev] virtual hosting and certificate checking
A couple of snips from the conversation: > For hosting providers it's usually an up-sell to your > customers to add security > because it's each domain owner's responsibility to > manage their own certificate. Extra cost and responsiblity can impede XMPP adoption.
Re: [jdev] virtual hosting and certificate checking
On 3/1/06, Norman Rasmussen <[EMAIL PROTECTED]> wrote: > Just like HTTPS, each hostname/certificate has to have it's own IP > address - this is so that we can tell which certificate to present > based on the IP the client has just connected to. In XMPP, TLS is negotatied after the client sends the domain to the server in the stream header. It is possible to support more than one domain on a single address:port pair.
Re: [jdev] virtual hosting and certificate checking
On Thursday 02 March 2006 06:36, Norman Rasmussen wrote: > > This can be problematic for virtual hosting. Consider the following > > scenario: > > > > - - shakespeare.lit runs an XMPP server. > > > > - - shakespeare.lit hosts XMPP services for denmark.lit, montague.lit, > > capulet.lit, etc. > > > > There are two possibilities I can see. > > Don't forget option #3: > > Just like HTTPS, each hostname/certificate has to have it's own IP > address - this is so that we can tell which certificate to present > based on the IP the client has just connected to. > > Unfortunately it's a wastage of IP addresses, but it's something that > most server admins / cert issuers understand already. Or, run each server on a different port. How much does a block of 50,000 IP addresses cost, anyway? I always get exhorbitant quotes back when I merely want to rent a block of 8. TX -- Email: [EMAIL PROTECTED] Jabber ID: [EMAIL PROTECTED] Web site: http://trypticon.org/ GPG Fingerprint: 9EEB 97D7 8F7B 7977 F39F A62C B8C7 BC8B 037E EA73 pgpzVvIiPszZz.pgp Description: PGP signature
Re: [jdev] virtual hosting and certificate checking
On Thursday 02 March 2006 05:59, Peter Saint-Andre wrote: > Let's say you are DreamHost, which has offered jabber services for years > now. You want to offer secure connections. But you host 50,000+ domains. > Are you going to have a separate certificate for each of those domains? Yes, because it's each domain owner's responsibility to manage their own certificate. That's the way it usually works with web hosting too, right? TX -- Email: [EMAIL PROTECTED] Jabber ID: [EMAIL PROTECTED] Web site: http://trypticon.org/ GPG Fingerprint: 9EEB 97D7 8F7B 7977 F39F A62C B8C7 BC8B 037E EA73 pgpsqsh2mPiuY.pgp Description: PGP signature
Re: [jdev] virtual hosting and certificate checking
On Wed, Mar 01, 2006 at 11:42:53AM -0700, Peter Saint-Andre wrote: > > There are two possibilities I can see. > > 1. Every time shakespeare.lit adds a new virtual host, it needs to > generate a new certificate. This is a real pain because of how > certificates are usually generated (e.g., now William Shakespeare needs > to be a root contact for denmark.lit, montague.lit, etc.). Well, he could also get a single certificate with a wildcard id-on-xmppAddr. > 2. Clients open TCP connections to shakespeare.lit (rather than > denmark.lit etc.) but specify the desired virtual hostname in the 'to' > address of the stream header, then check the certificate presented by > the server as either 'shakespeare.lit' or 'denmark.lit' (etc.). > > Option #2 is not explicitly forbidden by RFC 3920 as far as I can see, > because the phrase "the hostname as provided by the initiating entity" > is ambiguous -- it could mean > (a) the hostname at which the TCP connection was opened or As far as I can see, this is only allowed if the hostname was explicitly given by the user (or something acting on their behalf). If you resolved a SRV record, it's explicitly forbidden. After all, you've no reason to believe the DNS, and nothing other than the certificate to link the domain you want with the server you've connected to. > (b) the hostname of the stream header's 'to' address. That's what I took it to mean. The use of "hostname" in that bit of the XMPP RFC surprised me though. Surely it's almost always a domain name, and you'll look up the hostname? Brian
Re: [jdev] virtual hosting and certificate checking
As I understand it, the way dial-back works, you can make multiple 's2s' connections via a single dial-back session. IIRC, you just send the dial-back auth token down the existing connection and it adds the new server as a valid endpoint. With swapping to certs (and I assume SASL external?) does that mean one connection for every s2s connection - i.e. no piggybacking? I doubt that any arbitary hostname is allowed to be authorised, so I assume it would just be the id-on-xmppAddr's in the subjectAltName field? If all id-on-xmppAddr's are authorised, implementors need to be careful that hostname poisoning is not allowed. i.e. check that the dns entry matches the same ip/port of the existing connection, before checking the id-on-xmppAddr's on the already establised connection. -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
Re: [jdev] virtual hosting and certificate checking
On Wed, 1 Mar 2006, Peter Saint-Andre wrote: > > 2. Clients open TCP connections to shakespeare.lit (rather than > denmark.lit etc.) but specify the desired virtual hostname in the 'to' > address of the stream header, then check the certificate presented by > the server as either 'shakespeare.lit' or 'denmark.lit' (etc.). > > Option #2 is not explicitly forbidden by RFC 3920 as far as I can see, > because the phrase "the hostname as provided by the initiating entity" > is ambiguous -- it could mean (a) the hostname at which the TCP > connection was opened or (b) the hostname of the stream header's 'to' > address. Naturally we'll need to clarify this in rfc3920bis, but my > question now is: how do existing clients and servers handle this? I had thought that #2 was the only possible way, because even in the absence of virtual hosting you must be able to deal with server components - which from the point of view of other servers are just virtual hosts. For example jabber.org and conference.jabber.org have the same IP address but the server must present the appropriate certificate to other servers when they starttls. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ FISHER: CYCLONIC 5 TO 7. SNOW SHOWERS. GOOD OCCASIONALLY POOR.
Re: [jdev] virtual hosting and certificate checking
On 3/1/06, JD Conley <[EMAIL PROTECTED]> wrote: > We do this on the server side with a separate cert for each domain -- > even conference, users, and other sub-domains used in s2s. Some client > software packages present a warning when certificates aren't correct > (domain mismatch, etc) but many do not and just use the certificates for > encryption, not authentication. I can say from the client side that user's don't care about the warning, unfortunately. Psi will show the warnings but they can be surpressed and people often do this. -- Psi webmaster (http://psi-im.org) im:[EMAIL PROTECTED] http://halr9000.com
Re: [jdev] virtual hosting and certificate checking
> This can be problematic for virtual hosting. Consider the following > scenario: > > - - shakespeare.lit runs an XMPP server. > > - - shakespeare.lit hosts XMPP services for denmark.lit, montague.lit, > capulet.lit, etc. > > There are two possibilities I can see. Don't forget option #3: Just like HTTPS, each hostname/certificate has to have it's own IP address - this is so that we can tell which certificate to present based on the IP the client has just connected to. Unfortunately it's a wastage of IP addresses, but it's something that most server admins / cert issuers understand already. Of course, this isn't to say that Option #2 is a better idea, I was just saying that there's a work around for some servers/situations. -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
Re: [jdev] virtual hosting and certificate checking
On 3/1/06, Jonathan Siegle <[EMAIL PROTECTED]> wrote: > So I'm all for each domain having their own certificate. Also the > revocation list might be annoying if you have all 50k domains in one > cert and you have to add one domain one day and delete a domain the next > day... I'm with these guys. Also, cert management is usually delegated through an automated system such that the customer can purchase and install their own certificates. You are not going to have a situation where Dreamhost sells certs for HTTPS but then automatically SSLs every jabber vhost. At best they would give you 2 for 1, at worst you would purchase 2 certs and install them yourself. -- Psi webmaster (http://psi-im.org) im:[EMAIL PROTECTED] http://halr9000.com
Re: [jdev] virtual hosting and certificate checking
Peter Saint-Andre said the following on 3/1/06 1:59 PM: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 JD Conley wrote: address. Naturally we'll need to clarify this in rfc3920bis, but my question now is: how do existing clients and servers handle this? We do this on the server side with a separate cert for each domain -- even conference, users, and other sub-domains used in s2s. Some client software packages present a warning when certificates aren't correct (domain mismatch, etc) but many do not and just use the certificates for encryption, not authentication. Let's say you are DreamHost, which has offered jabber services for years now. You want to offer secure connections. But you host 50,000+ domains. Are you going to have a separate certificate for each of those domains? Or let's say you are Internet2 and you want to offer XMPP services for all member universities, of which there are several hundred. Here again, are you going to have a separate cert for each domain, or one cert with all the possible virtual hosting domains as CNs and/or id-on-xmppAddr subjectAltNames? You can only have one common name in a certificate(I think). I don't see what the limit of subjectAltnames is in rfc3280 but you can do wildcards. Managing 50k private keys would be nuts. Client support for traversing 50k subjectAltNames would be questionable. Obtaining an intermediate CA(http://www.geotrust.com/products/client_certificates/true_credentials.asp) from someone like GeoTrust or getting a wildcard cert(http://www.geotrust.com/products/ssl_certificates/wildcards.asp) might help. They might want to contact CACert. So I'm all for each domain having their own certificate. Also the revocation list might be annoying if you have all 50k domains in one cert and you have to add one domain one day and delete a domain the next day... -Jonathan smime.p7s Description: S/MIME Cryptographic Signature
RE: [jdev] virtual hosting and certificate checking
> JD Conley wrote: > >> address. Naturally we'll need to clarify this in rfc3920bis, but my > >> question now is: how do existing clients and servers handle this? > > > > We do this on the server side with a separate cert for each domain -- > > even conference, users, and other sub-domains used in s2s. Some client > > software packages present a warning when certificates aren't correct > > (domain mismatch, etc) but many do not and just use the certificates for > > encryption, not authentication. > > Let's say you are DreamHost, which has offered jabber services for years > now. You want to offer secure connections. But you host 50,000+ domains. > Are you going to have a separate certificate for each of those domains? > Or let's say you are Internet2 and you want to offer XMPP services for > all member universities, of which there are several hundred. Here again, > are you going to have a separate cert for each domain, or one cert with > all the possible virtual hosting domains as CNs and/or id-on-xmppAddr > subjectAltNames? Well, they certainly have separate certificates for https. For hosting providers it's usually an up-sell to your customers to add security on their http domains through a certificate purchased from an affiliate CA. I could easily see XMPP following the same route and/or using the same certificates. As a hosting provider I'd want separate certificates for all of my virtual domains so I could more easily provision domains on servers. I'd also want wildcard or multi-domain certificates for XMPP, but that wouldn't be necessary if, for example, S2S isn't enabled. -JD
Re: [jdev] virtual hosting and certificate checking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 JD Conley wrote: >> address. Naturally we'll need to clarify this in rfc3920bis, but my >> question now is: how do existing clients and servers handle this? > > We do this on the server side with a separate cert for each domain -- > even conference, users, and other sub-domains used in s2s. Some client > software packages present a warning when certificates aren't correct > (domain mismatch, etc) but many do not and just use the certificates for > encryption, not authentication. Let's say you are DreamHost, which has offered jabber services for years now. You want to offer secure connections. But you host 50,000+ domains. Are you going to have a separate certificate for each of those domains? Or let's say you are Internet2 and you want to offer XMPP services for all member universities, of which there are several hundred. Here again, are you going to have a separate cert for each domain, or one cert with all the possible virtual hosting domains as CNs and/or id-on-xmppAddr subjectAltNames? Just curious. :-) Peter - -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEBe8ENF1RSzyt3NURAlEHAKCceSBkbwf0X7zX+M1LObinIMT0WACePogI WSVsPnM7X8cy9b3nkEp5cpc= =ELGp -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature
RE: [jdev] virtual hosting and certificate checking
> address. Naturally we'll need to clarify this in rfc3920bis, but my > question now is: how do existing clients and servers handle this? We do this on the server side with a separate cert for each domain -- even conference, users, and other sub-domains used in s2s. Some client software packages present a warning when certificates aren't correct (domain mismatch, etc) but many do not and just use the certificates for encryption, not authentication. -JD Conley
