> They would either need the private key of the certificate holder (which they don't have), or a certificate signed by one of the roots installed on the system, which they also won't have.
Actually, this is fairly common for firewalls and other edge devices to do and is one of the problems with the "trust" in the CA system. You can get a "signing certificate" from various legitimate sources (ex. http://www.sslshopper.com/article-trusted-root-signing-certi... ) that allows your product/service to terminate SSL connections and then recreate a SSL connection. The user still sees their "lock" icon and thinks they have a secure https connection to their original site, when in fact they don't.
They do have a SSL connection to their site using a certificate - it's just NOT the certificate that the original site issued. This is why many of us are looking to protocols like DANE that uses DNSSEC to add a layer of integrity protection so that you can know that you are using the correct SSL certificate. (See http://www.internetsociety.org/deploy360/resources/dane/ )
Note that no new certificates need to be added to browsers. The signing certificates work with the existing root certificates that are already in browsers.
Ouch, I wasn't aware that CAs issued this type of "root" certificates. Is this very common, or will only some CAs do it? If the latter, I'll definitely remove them from my computers list of trusted CAs..
Edit: read the DANE article, seems very sensible and simple to implement that the server specifies valid certificates.
Actually, this is fairly common for firewalls and other edge devices to do and is one of the problems with the "trust" in the CA system. You can get a "signing certificate" from various legitimate sources (ex. http://www.sslshopper.com/article-trusted-root-signing-certi... ) that allows your product/service to terminate SSL connections and then recreate a SSL connection. The user still sees their "lock" icon and thinks they have a secure https connection to their original site, when in fact they don't.
They do have a SSL connection to their site using a certificate - it's just NOT the certificate that the original site issued. This is why many of us are looking to protocols like DANE that uses DNSSEC to add a layer of integrity protection so that you can know that you are using the correct SSL certificate. (See http://www.internetsociety.org/deploy360/resources/dane/ )
Note that no new certificates need to be added to browsers. The signing certificates work with the existing root certificates that are already in browsers.