Certificados Digitales con GNUTLS

De WikiSalud
Revisión a fecha de 13:07 8 mar 2016; Alortiz (Discusión | contribuciones)

(dif) ← Revisión anterior | Revisión actual (dif) | Revisión siguiente → (dif)
Saltar a: navegación, buscar

Contenido

Resumen

Introducción a la creación y administración de certificados digitales con GNUTLS

Introducción

GnuTLS es una librería de comunicaciones seguras que implementa los protocolos SSL, TLS y DTLS, y tecnologías relacionadas. Según parece, algunos personas en Debian han decidido darle un espaldarazo, siendo el caso que nos interesa el haber compilado el paquete OpenLDAP contra las librerías de GNUTLS (Buscar hacia el final en OpenLDAPSetup.

Probablemente hayas llegado acá por medio de la guía Configuraciones avanzadas para servidores LDAP en Debian

¿Que haremos?

A menos que puedas costear un certificado firmado por una Autoridad Certificadora y que sea compatible con GNUTLS, en esta guía actuaremos como una, lo que nos da la capacidad de escalar en cuanto al números de certificados queramos usar. Usaremos plantillas de respuesta no solo para acelerar la firma de certificados (Que no es poca cosa), sino para evitar errores a la hora de responder a las preguntas

Procedimiento

Paquetes necesarios

Instalamos los paquetes necesarios:

aptitude install ssl-cert gnutls-bin

Con el paquete ssl-cert, se ha creado un grupo ssl-cert. El esquema de permisos recomendado para los certificados digitales se basa en usar a dicho grupo de la siguiente forma:

chown root:ssl-cert <certificado>
chmod 550 <certificado>


Y agregar a cada usuario que deba tener acceso de lectura a dichos certificados a tal grupo

usermod -G ssl-cert <usuario>

Autoridad Certificadora

Es relativamente sencillo en términos de configuración ser una autoridad certificadora:

  • Creamos la llave privada
 certtool --generate-privkey --outfile CA-dominio.gob.sv.key
  • Opcionalmente, creamos una plantilla de respuesta para evitar errores a la hora de responder:
CA-sv.cfg
# X.509 Certificate options
#
# DN options

organization = "Institución"

unit = "Informática"

locality = "San Salvador"

state = "San Salvador"

country = SV

cn = "dominio.gob.sv"

expiration_days = 3650

email = "admin@dominio.gob.sv"

# Whether this is a CA certificate or not
ca

# Whether this certificate will be used to sign data (needed
# in TLS DHE ciphersuites).
signing_key

# Whether this key will be used to sign other certificates.
cert_signing_key

# Whether this key will be used to sign CRLs.
crl_signing_key

# Whether this key will be used to sign code.
code_signing_key

# Whether this key will be used to sign OCSP data.
ocsp_signing_key

# Whether this key will be used for time stamping.
time_stamping_key

# Whether this key will be used for IPsec IKE operations.
ipsec_ike_key

Modifique en la primera parte los siguiente atributos Hay algunos cambios obligatorios que habrá que realizar en la plantilla

cn
Se corresponde con el resultado del comando hostname -f
unit
En nuestro caso, lo usaremos para identificar el establecimiento
locality
Municipio donde se encuentra el establecimiento
state
Departamento donde se encuentra el establecimiento
email
Configure su correo como administrador del Servidor
  • Creamos un certificado auto-firmado, que según las propiedades configuradas arriba, resultará en un certificado de CA que podremos usar para firmar los demás.
    certtool --generate-self-signed --load-privkey CA-sv.key --outfile CA-sv.crt --template CA-sv.cfg

La parte más difícil de convertirse en una Autoridad Certificadora puede ser la parte administrativa. Los certificados debe estar lo suficientemente disponibles como para que las personas autorizadas puedan eventualmente firmar otros certificados, pero lo suficientemente seguros como para evitar que puedan ser robados. La pérdida de estos certificados hará que la validez de todos los demás sea puesta en duda.

Firmado de certificados digitales

Exploramos dos formas para firmar certificados. En ambos casos, empezamos por crear la clave privada del servidor y la plantilla de respuesta, para cuya modificación tenga en cuenta la explicación de los parámetros como se ha dado antes

certtool --generate-privkey --outfile `hostname -f`.key


`hostname -f`.cfg
# X.509 Certificate options
#
# DN options

organization = "Institución"

unit = "DTIC"

locality = "San Salvador"

state = "San Salvador"

country = SV

cn = "server.dominio.gob.sv"

expiration_days = 1825

email = "admin@dominio.gob.sv"

# Whether this certificate will be used for a TLS server
tls_www_server

# Whether this certificate will be used to sign data (needed
# in TLS DHE ciphersuites).
signing_key

# Whether this certificate will be used to encrypt data
encryption_key

# Whether this key will be used for IPsec IKE operations.
ipsec_ike_key

Firmado directo de certificados:

Este método no corresponde al comportamiento deseado de una Autoridad certificadora, pero es necesario darle un vistazo para que quede nota. Para firmarlo de esta forma, necesitamos que nos tener a la mano la plantilla de respuestas ($server.cfg) y la clave privada ($server.key) (Por ello no es el comportamiento adecuado para una Autoridad Certificadora)

Guardamos el nombre del host al cual vamos a crear su certificado

server="ldap2.dominio.gob.sv"

Y basta con usar el siguiente comando.

certtool --generate-certificate --load-ca-certificate CA-sv.crt \
--load-ca-privkey CA-sv.key --load-privkey $server.key \
--outfile $server.crt --template $server.cfg

Como resultado, tendremos un certificado $server.crt Enviamos al interesado los ficheros $server.crt y CA-sv.key

Firmado de certificados a partir de CSR

Este es el esquema que siempre debería usarse y representa el la relación real que se tiene como una Autoridad Certificadora.

El administrador del servidor debe crear la CSR ($server.csr) a partir de la clave privada ($server.key, que por otra parte, recordamos que debe guardarse con la mayor cautela posible) y de su plantilla de respuesta ($server.cfg) que ha creado antes:

certtool --generate-request --load-privkey `hostname -f`.key \
--outfile `hostname -f`.csr --template `hostname -f`.cfg

Nos envía el certificado de peticion de firma ($server.csr) y la plantilla de respuesta ($server.cfg), y ya con ellas firmamos, ejecutando el siguiente comando en el servidor que funciona como Autoridad Certificadora:

server="ldap2.dominio.gob.sv"
certtool --generate-certificate --load-ca-certificate CA-sv.crt \
--load-ca-privkey CA-sv.key  --load-request $server.csr \
--outfile $server.crt --template $server.cfg

Enviamos al usuario los ficheros $server.crt y CA-sv.key, tal como lo hubiéramos hecho con el método más directo.

Comprobación

Para cualquier servicio que configure, puede usar para una primera comprobación el comando

gnutls-cli  -p 636 `hostname -f` --x509cafile /etc/ssl/certs/CA-sv.crt

La salida tiene que ser bastante parecida a esta:

Processed 1 CA certificate(s).\
Resolving 'ldap2.dominio.gob.sv'...\
Connecting to '192.168.2.14:636'...\
- Certificate type: X.509
 - Got a certificate list of 2 certificates.
 - Certificate[0] info:
  - subject `C=SV,O=Ministerio de Salud,OU=Hospital de Acajutla,L=Acajutla,ST=La Libertad,CN=ldap2.cobros.gob.sv', issuer `C=SV,O=Ministerio de Salud,OU=DTIC,L=San Salvador,ST=San Salvador,CN=sv', RSA key 2432 bits, signed using RSA-SHA256, activated `2014-05-14 15:21:02 UTC', expires `2019-05-13 15:21:02 UTC', SHA-1 fingerprint `d00d408bdabafae04d89ab01fb419687e1204d70'
 - Certificate[1] info:
  - subject `C=SV,O=Institución,OU=DTIC,L=San Salvador,ST=San Salvador,CN=dominio.gob.sv'
, issuer `C=SV,O=Institución,OU=DTIC,L=San Salvador,ST=San Salvador,CN=sv', RSA key 2432 bits, signed using RSA-SHA256, activated `2014-05-12 20:02:29 UTC', expires `2024-05-09 20:02:29 UTC', SHA-1 fingerprint `69102e67d81a177f1d802eca6efd168871b40e4d'
- The hostname in the certificate matches 'server.dominio.gob.sv'.
- Peer's certificate is trusted
- Version: TLS1.2
- Key Exchange: RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Handshake was completed

- Simple Client Mode:

Y quedará habilitado un prompt en el cual podrá ejecutar órdenes propios del servicio que este usando. Vale destacar algunas partes del resultado:

 - Got a certificate list of 2 certificates.
Tantos certificados como puntos tenga su cadena de confianza
- The hostname in the certificate matches 'server.dominio.gob.sv'.
El certificado es el correcto para este servidor. El uso de comodines en el atributos CN puede ser una solución contra los problemas que puede causar la falta de control sobre la administración.
- Peer's certificate is trusted
El certificado público es el correcto para el servidor

Fuentes

Herramientas personales
Espacios de nombres

Variantes
Acciones
Navegación
Herramientas