Tengo un servidor maestro instalado en AWS y el servidor esclavo instalado en GoDaddy. ¿Cuántos certificados SSL necesito comprar? ¿Puedo usar un solo certificado para ambos?
Si el maestro y el esclavo usan el mismo nombre de host, o si tiene un certificado comodín y ambos usan subdominios del mismo dominio, no hay ninguna razón técnica por la que no pueda usar el mismo certificado SSL para ambos. Sin embargo, algunos emisores de certificados SSL los licencian por servidor, y puede estar incumpliendo las condiciones de su licencia.
Un servidor SSL puede usar un certificado si el nombre del servidor aparece en algún lugar del certificado (como dNSName dentro de la extensión del Asunto Alt Name, posiblemente con comodines, como se describe en RFC 2818 ). El "nombre del servidor" es lo que aparece en la URL utilizada por los clientes. Si el nombre en la URL no aparece en el certificado, el navegador del cliente se quejará (en voz alta).
El intercambio masivo de certificados es una cosa. Por ejemplo, el certificado SSL de Google contiene todos los siguientes nombres:
*.google.com
*.android.com
*.appengine.google.com
*.cloud.google.com
*.google-analytics.com
*.google.ca
*.google.cl
*.google.co.in
*.google.co.jp
*.google.co.uk
*.google.com.ar
*.google.com.au
*.google.com.br
*.google.com.co
*.google.com.mx
*.google.com.tr
*.google.com.vn
*.google.de
*.google.es
*.google.fr
*.google.hu
*.google.it
*.google.nl
*.google.pl
*.google.pt
*.googleapis.cn
*.googlecommerce.com
*.googlevideo.com
*.gstatic.com
*.gvt1.com
*.urchin.com
*.url.google.com
*.youtube-nocookie.com
*.youtube.com
*.youtubeeducation.com
*.ytimg.com
android.com
g.co
goo.gl
google-analytics.com
google.com
googlecommerce.com
urchin.com
youtu.be
youtube.com
youtubeeducation.com
Esto sugiere un intercambio extenso del mismo certificado, y eso es Google, Overlord of the Internet, nada menos.
La parte crítica no es el certificado per se, sino la clave privada . El certificado, debidamente dicho, contiene la clave pública; El poder del servidor reside en la clave privada correspondiente. Si dos servidores "comparten" un certificado, esto significa que ambos servidores tienen acceso a la clave privada.
El método de administración recomendado para las claves privadas es mantenerlas en un lugar local: se supone que el servidor mismo genera el par de claves (las claves privada y pública), luego envía la clave pública a la CA ( como parte de una "solicitud de certificado") para que la CA pueda crear (y firmar) el certificado. La clave privada, por lo tanto, nunca deja las entrañas del servidor, y esto es bueno, porque la clave privada debe mantenerse privada .
Cuando dos servidores contienen la clave privada, entonces esa clave debe haber viajado en algún momento. Hablando genéricamente, este viaje clave es sensible y peligroso, y debe hacerse solo con gran cuidado. Copiar la clave a través de SSH (es decir, un comando scp ) debería ser seguro. Alternativamente, la clave privada se puede empaquetar con el certificado en un archivo PKCS # 12 (también conocido como "archivo PFX") con cifrado basado en contraseña: esto brindará una protección decente para la clave mientras transita entre los dos servidores SI la contraseña es suficiente entropía (use una contraseña grande, gorda y muy aleatoria).
Sin embargo, sigue siendo que tendrá dos copias de la clave privada. Tener claves privadas específicas del servidor puede mejorar (ligeramente) la contención de daños en caso de un secuestro del servidor hostil.
Esta es una práctica bastante común. De hecho, la mayoría de los sitios web grandes utilizan el equilibrio de carga, que distribuye la carga del sitio en varios servidores. Hay dos formas en que esto se puede hacer. La primera es compartir la clave privada con cada servidor que va a hospedar el sitio, la segunda es usar un proxy SSL que mantenga la clave privada en el borde de una red privada de servidores que ejecutan el sitio (o posiblemente utilizando una comunicación cifrada alternativa) ). Ambos tienen sus fortalezas y debilidades.
Lo importante es que el certificado solo se puede usar para los sitios para los que se identifica como válidos. El objetivo de un certificado es validar que un servidor determinado es en realidad el sitio web con el que intentaba conectarse. Esto se hace mediante una Autoridad de certificación (CA) que verifica los detalles sobre el propietario de una clave privada y luego emite el certificado que básicamente dice que "estos detalles son válidos para el titular de la clave privada". Esos detalles son la información sobre el operador y el nombre del sitio o sitios que operan bajo esa clave privada.
Como han mencionado otros, también es importante darse cuenta de que algunas CA ponen limitaciones en el uso de certificados que brindan más allá de las limitaciones técnicas, por lo que es importante verificar que su CA permite su uso previsto o puede terminar con su certificado siendo revocado.
Por lo que yo sé, cuando queremos comprar un certificado SSL, debemos verificar que somos los propietarios legítimos del dominio. Esto se hace enviando un correo electrónico al proveedor de SSL usando una dirección de correo electrónico desde ese mismo dominio.
Puede tener un certificado SSL * .example y usarlo como:
abc.example.com def.example.com *.example.com
Pero este es más caro en comparación con comprar uno directamente para abc.example.com
El cliente típico no notará una diferencia entre el caso en el que los servidores usan certificados idénticos y el caso en que los servidores usan dos certificados diferentes para el mismo dominio.
Sin embargo, algunos clientes más pedantes acerca de la seguridad producirán una advertencia de seguridad, si ven que se están utilizando dos certificados diferentes para el mismo nombre de dominio.
Estas advertencias pueden producirse ya sea por el cliente individual que almacena en caché el certificado para validar conexiones posteriores o compartiendo los certificados en una red p2p.
Lea otras preguntas en las etiquetas tls