¿Por qué no se puede utilizar un certificado SSL para varias máquinas?

StackOverflow https://stackoverflow.com/questions/799272

  •  18-09-2019
  •  | 
  •  

Pregunta

Esta es la situación.Estoy realizando cambios en una aplicación pero no tengo un entorno de prueba.Hay un servidor de control de calidad para que lo use el equipo de pruebas, pero prefiero probar la aplicación en mi máquina local (implementar cambios en ese servidor podría interrumpir a los evaluadores).He configurado el entorno en mi máquina local, pero hay un problema.

La aplicación lee datos de una aplicación de terceros.Necesita un certificado SSL para conectarse al tercero.

Mi pregunta es, ¿por qué no puedo utilizar el certificado SSL del servidor de control de calidad en mi máquina local?

Hice una búsqueda superficial en Stack Overflow y, una vez que la CA emite el certificado, me parece que cualquier computadora podría usarlo.Supongo que he entendido mal alguna parte del proceso SSL.

¿Fue útil?

Solución

El certificado SSL está ligada al nombre de host real. Si usted tiene un certificado SSL para "qa.example.com", no va a funcionar en su máquina llamada "dev.example.com".

Tal vez ese es el problema que está teniendo.

Otros consejos

Estoy asumiendo que lo que usted describe está llevando a cabo la autenticación de cliente SSL a un tercero a distancia. Que su producto ha iniciado la conexión a los terceros partes como cliente y el tercero decide si su certificado es lo suficientemente bueno para la conexión.

Un certificado es esencialmente tres cosas:

  • Una clave privada - que sólo debe ser poseído por la entidad representada por el certificado
  • Una clave pública - una clave que es compartida con el mundo
  • información del certificado que incluye la clave pública, así como la identificación de los datos legibles por el titular de la clave -. Este es firmado criptográficamente por emisor del certificado

Así que ... es un poco más que una contraseña, pero es todos los datos, en el final.

La respuesta a si se puede instalar un certificado de cliente SSL en múltiples ubicaciones es sí y no. Sobre todo depende de los requisitos de seguridad del sistema de terceros y también cómo se ha almacenado que la clave privada.

Es posible almacenar un par de claves pública / privada y el certificado en un archivo - un estándar para esto es el PKCS # 12 . PKCS12s generalmente se fijan entonces con una contraseña. Muchas herramientas de software le permitirá crear el par de claves, lo almacena en un PKCS12, y hacer los diversos protocolos de certificados necesarios para solicitar y acabado de la emisión del certificado de un tercero (sospecharía que su tercero requiere que su certificado esté firmado por uno de una lista de emisores de confianza). Cada servidor de aplicaciones que he visto a continuación, se permitirá configurar el archivo de certificado como el certificado de cliente.

Si es así como se almacena el certificado SSL de control de calidad, entonces no debería haber un problema de instalarlo en su máquina.

Aquí está la trampa - A veces las órdenes de política de seguridad que los certificados se almacenan en un token de hardware. Esto es típicamente una medida de seguridad para garantizar que sólo una entidad puede utilizar el certificado. Copia de archivos de certificados de software funciona bien en un entorno de prueba, pero es una práctica de seguridad bastante pobre para una instalación del producto de trabajo. Si el servidor de control de calidad está usando un token de hardware, el hardware es probable que proteger la copia del par de claves privada a otra ubicación. Sin acceso a la clave privada pareja, usted será incapaz de realizar la solicitud SSL para el tercero -. Demostración de acceso a la clave privada es parte del protocolo

En ese caso, tendrá que solicitar su propio certificado y una clave para acceder a la tercera parte - a menos que su compañía ofrece un mecanismo para compartir los tokens de hardware. Eso no es del todo una locura - algunas granjas de servidores hacer eso - todos los servidores tienen la configuración de acceder a una, red HSM (Hardware Security Module) común y utilizar el par de claves. Esto sucede a menudo para los certificados de la sede de SSL, por lo que todos los servidores de la colección pueden parecen ser el mismo servidor. El truco es - ese tipo de hardware es bastante alto. Si está ejecutando algunas pruebas rápida y sucia, yo creo que sería poco probable que tenga acceso a ese tipo de sistema.

Me pregunto sobre los CERT de software y si es viable para que usted tenga una copia. Puede haber razones políticas que prohíben que ... pero no es difícil de instalar, y si acaba de hacer algunas pruebas, que realmente no arriesgar nada.

Sé que esto es un mensaje más viejo y puedo estar perdiendo algo, pero parece que todo el mundo se perdió la respuesta real aquí. Si usted quiere tener un certificado único que funciona en varios servidores utilizando varios nombres de host / dominios, a continuación, sólo tiene que comprar un certificado de SAN. Lo hacemos todo el tiempo en el trabajo ...

Esto es definitivamente posible hacer, de qué otra manera serían servidores trabajar en una granja de servidores web? Todos los servidores de una granja de servidores web tienen instalado el mismo certificado.

No tengo experiencia en Apache, pero para IIS el proceso se documenta aquí http: // support .microsoft.com / kb / 313299

Los certificados SSL se unen a un nombre de host. Así que para ser capaz de utilizarlo su máquina dev usted debe hacer el nombre de host determinación de que Dev máquina (es decir, el archivo utilizando anfitriones)

Típicamente, durante el apretón de manos SSL, el nombre de host que es parte del certificado está adaptada a el nombre de host del otro lado de una conexión SSL. Es por eso que un certificado está ligado a un nombre de host.

Hay varias maneras de salir de esto.

  1. Utilice un certificado comodín.
  2. Desactivar la verificación de nombre de host y aceptar el aumento del riesgo.
  3. Personalizar verificación de nombre de host.

http://support.godaddy .com / ayuda / article / 567 / what-is-a-wildcard-ssl-certificate y http://docs.oracle.com/ JavaSE / 7 / docs / api / javax / net / ssl / HostnameVerifier.html

@Kyle Jones - Mi pregunta es, ¿por qué no puedo usar el certificado SSL del servidor QA en mi máquina local?

@autonomatt - Subpregunta:Verisign y otras compañías le preguntan cuántos servidores está instalando el certificado SSL en ...conseguir que el cliente impar llame al decir que su navegador informa un problema con certificado ...

¿Legalmente?Puede instalar el certificado SSL en más de una computadora, pero es posible que no pueda hacerlo legalmente.La empresa Signing CA, al igual que Network Solutions, tiene una limitación legal en su compra.Cuando compra un certificado SSL, lo compra para instalarlo solo en una computadora.Debe leer los términos de la CA firmante a la que le compró el certificado.

¿Técnicamente?Técnicamente, a excepción de algunos servidores SSL acelerados por hardware, sí, puede copiar la CLAVE y el CRT a cualquier servidor web para brindar una conexión SSL válida.Tenga en cuenta que algunos certificados SSL se envían/proporcionan desde la CA con una cadena de certificados que también debe instalarse en el lado del servidor.Sin la cadena de certificados instalada, el navegador web del cliente no puede validar el certificado SSL correctamente.Debe verificar si una cadena de CA cuenta con el certificado SSL proporcionado por la CA firmante.

Requisitos de resolución de IP. Y el certificado SSL está vinculado a un nombre de host.Cuando el navegador web de un cliente realiza una solicitud a un servidor, se conecta a una dirección IP resuelta a partir de un nombre de dominio y luego comienza el proceso de protocolo de enlace SSL/TLS.El servidor web que responde en esa dirección IP debe presentar el certificado SSL con un nombre común que el navegador web del cliente solicita a través de la dirección IP.Esto significa que sólo se puede configurar un certificado SSL por dirección IP.El cliente solo envía solicitudes HTTP 1.1 cifradas, por lo que el servidor no tiene idea de cuál es la solicitud de dominio real del cliente hasta después del protocolo de enlace SSL/TLS.

Resolución de IP de no producción. Para instalar en otro lugar, el navegador web debe resolver correctamente el nombre de host en la dirección IP.Entonces, si se encuentra en un entorno que no es de producción, el cliente debe resolver la dirección IP de manera diferente que en el entorno de producción.Esto se puede realizar con servidores DNS alternativos o el archivo de hosts locales de todas las máquinas que necesitan la resolución DNS alternativa.

Proceso de instalación técnica. Para instalar el certificado SSL en otra máquina, copie la CLAVE, SSL CRT y la cadena CA en los archivos apropiados configurados para el servidor web.Si es Apache, todo puede ir en un archivo PEM para el certificado SSL.

Luego, asegúrese de que el servidor web proporcione este archivo PEM en la dirección IP que resuelve el nombre común en el certificado SSL.

Certificados SSL comodín. Algunas CA también proporcionan certificados SSL Willdcard, como *.domain.com.Tenga en cuenta que el navegador web debe reconocer este tipo de certificado y solo protege un nivel de subdominio.Por lo tanto, www.dominio.com se puede proteger, pero www.sub1.dominio.com hará que el navegador web del cliente le dé al usuario del cliente un error de validación.

Algunas razones por las que los navegadores web de los clientes reciben errores de validación del certificado SSL:

  1. si la cadena CA es necesaria pero el servidor web no la proporciona.
  2. Si la CA de firma raíz no es una CA confiable en las autoridades SSL del navegador web del cliente, esto siempre es cierto para los certificados SSL autofirmados.
  3. si el navegador web del cliente solicita un dominio a través de SSL que no coincide con el nombre común del certificado SSL.
  4. si el navegador del cliente no puede acceder a los puntos de distribución CRL x509 desde la CA firmante, un cliente en una red restringida o cerrada no podrá validar el certificado SSL.La URL de la CRL se proporciona durante el protocolo de enlace SSL/TLS.Ver también: http://en.wikipedia.org/wiki/Revocation_list#Problems_with_CRLs .

El certificado contiene información: 1) Los detalles como nombre, dominio, dirección, fecha de caducidad de la clave, etc sobre la empresa / indvidual que contiene el certificado. 2) Tiene la clave pública. 3) Algunos datos cifrados. Este es el punto crucial.

Estos datos encriptados es toda la información del usuario, así como el público presente clave en el certificado que ha sido firmado por la clave privada de la CA que emitió el certificado.

Cuando el navegador recibe el certificado, se trata de de-signo datos cifrados utilizando la clave pública de la CA que ya esté incrustado en el navegador. Así que si toda la información presente en los partidos certificado después de-firma, entonces se asegura que el dueño de ese dominio se menciona en el certificado tiene la clave privada correspondiente a la clave pública mencionada en el certificado.

Así que el punto crucial es que, si alguien publica (como sitios web no) que soy el propietario del certificado, que significa que, la persona / empresa posee la correspondiente clave privada pareja.

SO Volviendo a EMISIÓN: ". La aplicación lee datos de una aplicación de terceros Se necesita un certificado SSL para conectarse a la tercera parte" El verdadero problema es que

y esto lo certificado se ha diseñado. Básicamente su aplicación desea hacer la conexión SSL con la aplicación de terceros, y si usted tiene el certificado, que se ajustan todas. Así, en un primer momento supongo que usted ha puesto el certificado en el directorio incorrecto para que su aplicación no es capaz de leer y no es capaz de hacer la conexión SSL con el tercero. O hay algún problema de archivo de configuración.

Sé que la respuesta no sirve de nada, pero pensé mejor escribir lo que siento.

Creo que es necesario dar más detalles sobre su entorno un poco más, pero tal vez no ha copiado la parte clave privada del certificado en el equipo local. La clave privada y pública son necesarios para utilizar el certificado. Estoy asumiendo que ya se escribe "lee de un tercero" que está utilizando un certificado de cliente.

En estas situaciones, el tercero en general, hará una de dos cosas. Proporcionarle acceso a un entorno limitado de control de calidad que no requiere de un CERT. o le permiten hacer un certificado temporal que van a aceptar que no es validada por una autoridad de certificación. Sería extraño que un proveedor de servicios web de terceros que no prevé la necesidad de tener diferentes control de calidad y prod. ambientes.

Bueno, técnicamente, un certificado (exportado de estas herramientas por ahí PKI) no contendrá la clave privada. Por lo que incluso en el entorno de carga equilibrada, copia del certificado de llanura no ayudará ??

Además, cuando generamos certs utilizando herramientas de PKI, puede proporcionar una cadena arbitraria para el DN (como "CN = xyz, OU = TTR, O = x"). Me pregunto cuál sería el comportamiento si diferentes máquinas utilizan el mismo DN para crear los certs?

Entiendo que mi respuesta a esta pregunta es demasiado tarde en el thread..but me encontré con el mismo problema hoy al instalar el mismo certificado a 2 servidores en una configuración del equilibrador de carga, sistema operativo = Windows 2008 / IIS 7.5 y fue capaz de averiguar la solución.

yo era capaz de instalarlo en el primer servidor haciendo clic en 'Completar solicitud de certificado', y navegando a la ubicación en el certificado 'abc.cer' se encuentra (Suponga que tiene el certificado ya con usted). A continuación, he copiado el mismo 'abc.cer' en el segundo servidor y traté 'Completar solicitud de certificado' y que no funcionaría. aparecería como el certificado instalado, pero desaparecería tan pronto como refrescado el Administrador de IIS. Luego probé la opción de 'exportar' el certificado desde el primer servidor (genera un archivo de extensión .pfx) y luego se importa la misma en el segundo servidor. Este método ha funcionado.

Depende de lo que quiere decir con esto

Un certificado comodín puede ser utilizado para múltiples hosts con diferentes registros A.

Por ejemplo, usted tiene un certificado comodín para el dominio *.stackoverflow.com. Puede tener CA aprobado TLS, siempre y cuando los nuevos servidores que se están ejecutando están utilizando un subdominio del dominio stackoverflow.com

es decir. mail-server.stackoverflow.com

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top