Por fin después de tanto batallar pudimos encontrar la respuesta de esta escollo que ciertos de nuestros usuarios de nuestra web han tenido. Si tienes algún dato que compartir puedes dejar tu comentario.
- 18.9.1. Configuración básica
- 18.9.2. Configuración de OpenSSL
- 18.9.3. Usar certificados de cliente
- 18.9.4. Uso de archivos del servidor SSL
- 18.9.5. Creando Certificados
PostgreSQL tiene soporte nativo para usar conexiones SSL para encriptar las comunicaciones cliente / servidor para mayor seguridad. Esto requiere que OpenSSL esté instalado en los sistemas cliente y servidor y que el soporte en PostgreSQL esté habilitado en el momento de la compilación (consulte Capítulo 16).
18.9.1. Configuración básica
Con el soporte SSL compilado, el servidor PostgreSQL se puede iniciar con SSL habilitado configurando el parámetro ssl en on en postgresql.conf. El servidor escuchará las conexiones normales y SSL en el mismo puerto TCP y negociará con cualquier cliente que se conecte si se debe utilizar SSL. Por defecto, esto es a opción del cliente; consulte la Sección 20.1 sobre cómo configurar el servidor para que requiera el uso de SSL para algunas o todas las conexiones.
Para comenzar en modo SSL, los archivos que contienen el certificado del servidor y los key debe existir. De forma predeterminada, se espera que estos archivos se denominen server.crt y server.key, respectivamente, en el directorio de datos del servidor, pero se pueden especificar otros nombres y ubicaciones utilizando los parámetros de configuración ssl_cert_file y ssl_key_file.
En los sistemas Unix, los permisos en server.key debe prohibir cualquier acceso al mundo o grupo; lograr esto por el comando chmod 0600 server.key. Alternativamente, el archivo puede ser propiedad de root y tener acceso de lectura de grupo (es decir, 0640 permisos). Esa configuración está destinada a instalaciones donde certificado y key los archivos son administrados por el sistema operativo. El usuario bajo el cual se ejecuta el servidor PostgreSQL debe convertirse en miembro del grupo que tiene acceso a esos certificados y key archivos.
Si el directorio de datos permite el acceso de lectura grupal, es posible que los archivos de certificado deban ubicarse fuera del directorio de datos para cumplir con los requisitos de seguridad descritos anteriormente. Generalmente, el acceso de grupo está habilitado para permitir que un usuario sin privilegios haga una copia de seguridad de la base de datos y, en ese caso, el software de copia de seguridad no podrá leer los archivos del certificado y probablemente generará un error.
Si el privado key está protegido con una frase de contraseña, el servidor solicitará la frase de contraseña y no se iniciará hasta que se haya ingresado. El uso de una frase de contraseña de forma predeterminada deshabilita la capacidad de cambiar la configuración SSL del servidor sin reiniciar el servidor, pero consulte ssl_passphrase_command_supports_reload. Además, privados protegidos por contraseña keys no se puede utilizar en absoluto en Windows.
El primer certificado en server.crt debe ser el certificado del servidor porque debe coincidir con el certificado del servidor key. Los certificados de “intermedio“ Las autoridades de certificación también se pueden agregar al archivo. Hacer esto evita la necesidad de almacenar certificados intermedios en los clientes, asumiendo que los certificados raíz e intermedios se crearon con v3_ca extensiones. (Esto establece la restricción básica del certificado de CA para true.) Esto permite una caducidad más fácil de los certificados intermedios.
No es necesario agregar el certificado raíz a server.crt. En cambio, los clientes deben tener el certificado raíz de la cadena de certificados del servidor.
18.9.2. Configuración de OpenSSL
PostgreSQL lee el archivo de configuración de OpenSSL en todo el sistema. De forma predeterminada, este archivo se denomina openssl.cnf y se encuentra en el directorio informado por openssl version -d. Este valor predeterminado se puede anular configurando la variable de entorno OPENSSL_CONF al nombre del archivo de configuración deseado.
OpenSSL admite una amplia gama de cifrados y algoritmos de autenticación, de diferente intensidad. Si bien se puede especificar una lista de cifrados en el archivo de configuración de OpenSSL, puede especificar cifrados específicamente para que los utilice el servidor de base de datos modificando ssl_ciphers en postgresql.conf.
Nota
Es posible tener autenticación sin sobrecarga de cifrado utilizando
NULL-SHAoNULL-MD5cifrados. Sin embargo, un intermediario podría leer y pasar comunicaciones entre el cliente y el servidor. Además, la sobrecarga de cifrado es mínima en comparación con la sobrecarga de autenticación. Por estas razones, no se recomiendan los cifrados NULL.
18.9.3. Usar certificados de cliente
Para solicitar al cliente que proporcione un certificado de confianza, coloque los certificados de las autoridades de certificación raíz (CA) en las que confía en un archivo en el directorio de datos, establezca el parámetro ssl_ca_file en postgresql.conf al nuevo nombre de archivo y agregue la opción de autenticación clientcert=verify-ca o clientcert=verify-full al apropiado hostssl línea (s) en pg_hba.conf. A continuación, se solicitará un certificado al cliente durante el inicio de la conexión SSL. (Ver Sección 33.18 para obtener una descripción de cómo configurar certificados en el cliente).
Para hostssl entrada con clientcert=verify-ca, el servidor verificará que el certificado del cliente esté firmado por una de las autoridades de certificación de confianza. Si clientcert=verify-full se especifica, el servidor no solo verificará la cadena de certificados, sino que también comprobará si el nombre de usuario o su asignación coincide con el cn (Nombre común) del certificado proporcionado. Tenga en cuenta que la validación de la cadena de certificados siempre está garantizada cuando cert se utiliza el método de autenticación (consulte la Sección 20.12).
Los certificados intermedios que se encadenan a los certificados raíz existentes también pueden aparecer en el archivo ssl_ca_file si desea evitar almacenarlos en los clientes (asumiendo que los certificados raíz e intermedios se crearon con v3_ca extensiones). Las entradas de la Lista de revocación de certificados (CRL) también se comprueban si se establece el parámetro ssl_crl_file.
los clientcert La opción de autenticación está disponible para todos los métodos de autenticación, pero solo en pg_hba.conf líneas especificadas como hostssl. Cuando clientcert no se especifica o se establece en no-verify, el servidor aún verificará cualquier certificado de cliente presentado con su archivo de CA, si hay uno configurado, pero no insistirá en que se presente un certificado de cliente.
Hay dos enfoques para hacer que los usuarios proporcionen un certificado durante el inicio de sesión.
El primer enfoque hace uso de la cert método de autenticación para hostssl entradas en pg_hba.conf, de modo que el certificado en sí se utiliza para la autenticación y, al mismo tiempo, proporciona seguridad de conexión SSL. Consulte la Sección 20.12 para obtener más detalles. (No es necesario especificar ninguna clientcert opciones explícitamente cuando se utiliza el cert método de autenticación.) En este caso, el cn (Nombre común) proporcionado en el certificado se compara con el nombre de usuario o una asignación aplicable.
El segundo enfoque combina cualquier método de autenticación para hostssl entradas con la verificación de certificados de cliente mediante el establecimiento de la clientcert opción de autenticación para verify-ca o verify-full. La primera opción solo obliga a que el certificado sea válido, mientras que la segunda también asegura que el cn (Nombre común) en el certificado coincide con el nombre de usuario o una asignación aplicable.
18.9.4. Uso de archivos del servidor SSL
La Tabla 18.2 resume los archivos que son relevantes para la configuración de SSL en el servidor. (Los nombres de archivo mostrados son nombres predeterminados. Los nombres configurados localmente pueden ser diferentes).
Cuadro 18.2. Uso de archivos del servidor SSL
| Expediente | Contenido | Efecto |
|---|---|---|
ssl_cert_file ($PGDATA/server.crt) |
certificado de servidor | enviado al cliente para indicar la identidad del servidor |
ssl_key_file ($PGDATA/server.key) |
servidor privado key | prueba que el propietario envió el certificado del servidor; no indica que el propietario del certificado sea de confianza |
| ssl_ca_file | autoridades de certificación confiables | comprueba que el certificado del cliente esté firmado por una autoridad certificadora de confianza |
| ssl_crl_file | certificados revocados por las autoridades de certificación | el certificado de cliente no debe estar en esta lista |
El servidor lee estos archivos al iniciar el servidor y cada vez que se vuelve a cargar la configuración del servidor. Sobre Ventanas sistemas, también se vuelven a leer cada vez que se genera un nuevo proceso de backend para una nueva conexión de cliente.
Si se detecta un error en estos archivos al iniciar el servidor, el servidor se negará a iniciar. Pero si se detecta un error durante la recarga de la configuración, los archivos se ignoran y se sigue utilizando la configuración SSL anterior. Sobre Ventanas sistemas, si se detecta un error en estos archivos al iniciar el backend, ese backend no podrá establecer una conexión SSL. En todos estos casos, la condición de error se informa en el registro del servidor.
18.9.5. Creando Certificados
Para crear un certificado autofirmado simple para el servidor, válido por 365 días, use el siguiente comando de OpenSSL, reemplazando dbhost.yourdomain.com con el nombre de host del servidor:
openssl req -new -x509 -days 365-nodes -text-out server.crt -keyout server.key-subj "/CN=dbhost.yourdomain.com"
Entonces hazlo:
chmod og-rwx server.key
porque el servidor rechazará el archivo si sus permisos son más liberales. Para obtener más detalles sobre cómo crear su servidor privado key y certificado, consulte la documentación de OpenSSL.
Si bien se puede usar un certificado autofirmado para las pruebas, en producción se debe usar un certificado firmado por una autoridad de certificación (CA) (generalmente una CA raíz de toda la empresa).
Para crear un certificado de servidor cuya identidad pueda ser validada por los clientes, primero cree una solicitud de firma de certificado (CSR) y una pública / privada. key expediente:
openssl req -new -nodes -text-out root.csr -keyout root.key-subj "/CN=root.yourdomain.com" chmod og-rwx root.key
Luego, firme la solicitud con el key para crear una autoridad de certificación raíz (utilizando la ubicación predeterminada del archivo de configuración de OpenSSL en Linux):
openssl x509 -req -in root.csr -text-days 3650 -extfile /etc/ssl/openssl.cnf -extensions v3_ca -signkey root.key-out root.crt
Finalmente, cree un certificado de servidor firmado por la nueva autoridad de certificación raíz:
openssl req -new -nodes -text-out server.csr -keyout server.key-subj "/CN=dbhost.yourdomain.com" chmod og-rwx server.key openssl x509 -req -in server.csr -text-days 365 -CA root.crt -CAkey root.key-CAcreateserial -out server.crt
server.crt y server.key debe almacenarse en el servidor, y root.crt debe almacenarse en el cliente para que el cliente pueda verificar que el certificado hoja del servidor fue firmado por su certificado raíz de confianza. root.key debe almacenarse fuera de línea para su uso en la creación de certificados futuros.
También es posible crear una cadena de confianza que incluya certificados intermedios:
# root openssl req -new -nodes -text-out root.csr -keyout root.key-subj "/CN=root.yourdomain.com" chmod og-rwx root.key openssl x509 -req -in root.csr -text-days 3650 -extfile /etc/ssl/openssl.cnf -extensions v3_ca -signkey root.key-out root.crt # intermediate openssl req -new -nodes -text-out intermediate.csr -keyout intermediate.key-subj "/CN=intermediate.yourdomain.com" chmod og-rwx intermediate.key openssl x509 -req -in intermediate.csr -text-days 1825 -extfile /etc/ssl/openssl.cnf -extensions v3_ca -CA root.crt -CAkey root.key-CAcreateserial -out intermediate.crt # leaf openssl req -new -nodes -text-out server.csr -keyout server.key-subj "/CN=dbhost.yourdomain.com" chmod og-rwx server.key openssl x509 -req -in server.csr -text-days 365 -CA intermediate.crt -CAkey intermediate.key-CAcreateserial -out server.crt
server.crt y intermediate.crt debe concatenarse en un paquete de archivos de certificado y almacenarse en el servidor. server.key también debe almacenarse en el servidor. root.crt debe almacenarse en el cliente para que el cliente pueda verificar que el certificado hoja del servidor fue firmado por una cadena de certificados vinculado a su certificado raíz de confianza. root.key y intermediate.key debe almacenarse fuera de línea para su uso en la creación de certificados futuros.
| Anterior | Hasta | próximo |
| 18,8. Opciones de cifrado | Hogar | 18.10. Conexiones TCP / IP seguras con cifrado GSSAPI |
Sección de Reseñas y Valoraciones
Recuerda que puedes difundir esta sección si te valió la pena.