Pautas para el uso de los Certificados Digitales

Introducción

El propósito de este documento es orientar al cliente que integrará su producto con Portal Carat. sobre el uso de certificados digitales.

El propósito de esto es presentar, de manera simplificada, pequeñas pautas sobre el uso de estos para garantizar la seguridad de la comunicación entre el Portal Carat y el producto del cliente.

Si es necesario profundizar en los temas presentados, sugerimos consulte otra literatura y / o fuentes en Internet.

Certificado digital

El Certificado Digital o Certificado de Clave Pública (sólo ‘certificado’ de ahora en adelante) es un documento digital que está destinado a certificar la identidad de una persona o entidad en la comunicación digital. Una forma de comunicación digital segura ampliamente utilizada en Internet es HTTPS, que es una abreviatura de HTTP a través de SSL / TLS.

El certificado generalmente lo solicita la persona o entidad y lo emite una CA (autoridad de certificación o Certification Authority, en inglés) como Verisign, CertSign, etc. Un certificado válido es aquel que, entre otros requisitos, está dentro de su fecha de vencimiento y está firmado por una CA de confianza.

Como ejemplo de su uso, cuando utilizamos un navegador (Firefox, Chrome, etc.) para acceder a un sitio web que ofrece seguridad en las comunicaciones mediante HTTPS, suele mostrarse el certificado que utiliza el servidor del sitio web, generalmente simbolizado por un icono de candado que es ubicado cerca de la ubicación donde se muestra la URL. Al hacer clic en este icono de candado puede ver las características de este certificado.

La principal característica de un certificado es el nombre al que se emite, es decir, cuál es el nombre identificado en el certificado. En la imagen de abajo podemos ver la información, donde el certificado es emitido por la CA "Network Solutions DV Server" y emitido para el nombre esitef.softwareexpress.com.br

Certificados self-signed

Para ambientes de prueba, hay casos en los que no es posible obtener un certificado válido, por lo que a veces se utiliza un certificado auto-firmado o self-signed.

Un certificado self-signed es generado y firmado por la propia persona / entidad, y no se acepta como confiable para una comunicación segura. Por ejemplo, al acceder a un sitio web utilizando browser a través de HTTPS, donde el servidor utiliza un certificado self-signed., se muestra una advertencia similar a las imágenes a continuación en el browser:

Firefox

Chrome

Internet Explorer

Al navegar por estos sitios web que utilizan certificados self-signed, tenemos la opción de confiar en el sitio web y acceder a ellos, aunque el certificado presentado en ellos no sea de confianza, asumiendo el riesgo de acceder y enviar información a un sitio web que no tiene la certificado de confianza o incluso con un certificado que no tiene la identidad de quien dice ser. Esto también se puede aplicar a la comunicación entre servidores.

Comunicación de Portal Carat con servidores cliente

Portal Carat a menudo se comunica con los servidores del cliente a través de los POST’s HTTPS para validar la autenticidad de la solicitud, como en transacciones de recarga y cancelaciones de pagos. Para esta comunicación, el servidor del cliente debe presentar certificados válidos que garanticen la seguridad de la información transmitida. En el entorno de producción de Portal Carat, en general, todos los clientes ya cuentan con una infraestructura lista para usar, con servidores con sus respectivos certificados válidos y firmados por CA’s reconocidas en el mercado.

Sin embargo, en la etapa de homologación, muchos sistemas aún se encuentran en la fase de prueba o desarrollo, utilizando certificados temporales y, a menudo, autofirmados. En este caso utilizamos un enfoque similar al mencionado en el ítem anterior, haciendo excepciones para que Portal Carat confíe en un servidor que presenta un certificado self-signed. Esto se hace importándolo a una lista de certificados de confianza. De esta forma, facilitamos el proceso de homologación de los sistemas del cliente.

Como la tecnología utilizada en el Portal Carat sigue la especificación de comunicación HTTPS [RFC-2818] (https://tools.ietf.org/html/rfc2818), este enfoque tiene algunas restricciones:

• El certificado debe ser válido, es decir, al menos debe tener su fecha de caducidad adecuada para el período en uso;

• La identificación del servidor del cliente debe ser compatible con el nombre presentado en el certificado. Por lo tanto, las siguientes situaciones resultarán en fallas de comunicación:

  • Un certificado emitido a www.domain.com no será compatible con un servidor identificado como domain.com o tests.domain.com, ya que se consideran identificaciones diferentes.
  • Un servidor con una única IP, pero con varios dominios y, respectivamente, varios certificados, se puede identificar de formas diferentes e inesperadas.

• La especificación no permite certificados emitidos a la dirección IP de un servidor, a menos que se agreguen al certificado Nombres alternativos (Subject Alternative Names) de IP’s o dominios.

Por lo tanto, los certificados que se encuentren en condiciones fuera de la especificación no serán aceptados en la comunicación HTTPS incluso si se importan en la lista de certificados confiables en Portal Carat. Este requisito en el ambiente de aprobación de Pagos Online prepara al cliente para garantizar el uso de un certificado emitido correctamente por una CA para el sistema en el entorno de producción.

Creación de certificados self-signed

Hay varias formas conocidas de generar certificados auto-firmados o self-signed. Aquí presentaremos uno de ellos, usando la herramienta openssl, que se puede encontrar en los paquetes del servidor web Apache. Todas las referencias y comandos que se presentan a continuación se basan en las versiones Apache HTTP 2.2 y openssl 0.9.8 en el entorno de Windows. Si el cliente lo prefiere, se puede realizar un procedimiento análogo en un entorno Linux, con las herramientas y adaptaciones necesarias.

Como preparación ambiental, sugerimos:

• Cree una carpeta separada llamada openssl (o elija cualquier otro nombre) y copie tres archivos existentes en% APACHE_HOME% / bin: libeay32.dll, ssleay.dll y zlib1.dll. Copie estos archivos en el directorio: Windows \ System32.
• Copie el archivo openssl.exe existente en% APACHE_HOME% / bin en el directorio openssl.
• Copie el archivo openssl.cnf existente en% APACHE_HOME% / conf en el directorio openssl.

Configuración de openssl: openssl.cnf

El archivo openssl.cnf contiene la configuración para generar certificados. Inicialmente, cree una copia de esto con otro nombre (por ejemplo, openssl_editado.cnf o un nombre de su elección).

Sugerimos editar los siguientes campos del archivo openssl_editado.cnf para facilitar su uso futuro:

• Quite el comentario (elimine el carácter #) del principio de la siguiente línea:

  req_extensions = v3_req # Las extensiones para agregar a una solicitud de certificado

• Justo debajo, agregue o cambie los valores predeterminados para los campos:

  • countryName_default = BR (o otro país)
  • stateOrProvinceName_default = \<nombre del estado>
  • localityName_default = \<Nombre de la ciudad>
  • 0.organizationName_default = \<Nombre de la Empresa>
  • organizationalUnitName_default = \<nombre del sector, equipo>
  • commonName_default = \<nombre común a ser registrado>
  • emailAddress_default = \<email>

• Después escribir:

  [ v3_req ]

  # Extensions to add to a certificate request

  basicConstraints = CA:FALSE

  keyUsage = nonRepudiation, digitalSignature, keyEncipherment

• Añadir:

  subjectAltName=@alt_names

  [alt_names]

• Y luego, justo debajo, añada nombres alternativos al commonName, en forma de DNS o IP, como en los ejemplos siguientes, según las necesidades de identificación del servidor:

  DNS.1 = www.dominio.com

  DNS.2 = *.dominio.com

  ...

  IP.1 = 192.168.4.34

  IP.2 = 200.122.10.66

  ...

Con esto concluye la personalización del archivo de configuración openssl.

comandos openssl para generar certificado

Supongamos que queremos generar un certificado de nombre de dominio.

• Cree una clave privada RSA de 2048 bits ejecutando el siguiente comando en el directorio openssl:

  openssl genrsa -out domain.pem 2048

• Ejecute el siguiente comando para solicitar la creación del certificado

  openssl req -config openssl_editado.cnf -extensions v3_req -new -out domain.cer -keyout domain.pem

Luego de la ejecución de este comando, se solicitarán algunos datos (País, Estado, Ciudad, Nombre y Unidad Organizacional, correo electrónico) para ser llenados como opción y dos para ser llenados: el Common Name que es el dominio asociado con el certificado (o la IP del servidor) y una contraseña a asociar con la clave privada. De forma predeterminada, acepte las opciones predeterminadas sugeridas.

• Luego, ejecute el siguiente comando para crear la clave privada sin contraseña (se eliminará la contraseña asociada con la clave privada). De esta forma, la clave solo será legible por el servidor Apache y el administrador:

  openssl rsa –in domain.pem –out domain.key

Después de ejecutar este comando, se le pedirá la contraseña de la clave privada.

Se recomienda eliminar el archivo .rnd ya que contiene información confidencial sobre la creación de la clave. Eliminarlo evita los ataques criptográficos contra la clave privada.

• Finalmente, ejecute el siguiente comando para crear el certificado firmado que durará un año:

  openssl x509 -in domain.cer -out domain.cer -req -signkey domain.key -days 365 -extensions v3_req extfile openssl_editado.cnf

Los archivos domain.cer y domain.key se utilizarán en el servidor.

Instalación de certificado self-signed generado en el servidor Apache

Aquí presentaremos un ejemplo de instalación del certificado en el servidor HTTP Apache 2.2.

• En la carpeta donde está instalado Apache, abra la carpeta conf y abra el archivo de configuración httpd-ssl.conf;

• Edite los siguientes elementos a continuación en el archivo httpd-ssl.conf:

  ServerName <nombre/dominio o IP del servidor>

  Ej: www.dominio.com.br o IP 200.###.###.###

  SSLCertificateFile <camino+nombre del certificado>

  Ej: `%APACHE_HOME%/conf/dominio.cer`

  SSLCertificateKeyFile <camino+nombre del archivo de claves del certificado>

  Ej: %APACHE_HOME%/conf/dominio.key

• Reiniciar Apache

Verificación del certificado generado

Para verificar que el certificado se generó e instaló correctamente, abra un navegador de su elección e ingrese la URL a la que Apache responde, y haga clic en el ícono de candado para abrir el certificado. Las figuras siguientes ilustran la visualización del certificado en diferentes entornos:

Detalle del certificado en entorno Windows

Detalle del certificado en Firefox