Introducción
Bizagi soporta integración con sistemas de administración de identidad y accesos (por ejemplo, administradores o proveedores de identidad) a través de estándares y protocolos seguros de la industria.
Dentro de esos protocolos seguros, se soporta SAML 2.0 y su uso requiere la emisión e instalación de certificados.
Los requisitos se deben al intercambio de Bizagi como Proveedor de Servicios (SP por sus siglas en inglés) y su Proveedor de Identidad (IdP por sus siglas en inglés) con SAML, en donde dichos mensajes deben estar debidamente firmados.
Para algunos IdP's (de acuerdo a su soporte a opciones extendidas), se puede usar otro certificado para encriptar los mensajes que se intercambian.
Certificados autofirmados
En cuanto a los certificados que se utilizan para firmar o encriptar mensajes, usted puede usar certificados auto-firmados sin que esto suponga alguna preocupación de seguridad.
Los certificados auto-firmados son los que no fueron emitidos por una entidad de certificados pública, y se pueden generar localmente por medio de herramientas de SDS como keytool de Java, OpenSSL u otros.
|
Otra alternativa para generar certificados auto-firmados es desde el Customer Portal, para ello consulte la documentación de Certificados de Autenticación. |
Este artículo describe cómo puede emitir e instalar certificados auto-firmados; esto es, si planea utilizarlos.
La siguiente imagen representa (a grandes rasgos) cómo se trabaja con certificados; considerando que la autoridad de certificados no necesariamente sea externa sino una configurada localmente dependiendo del uso de un certificado auto-firmado.
La anterior imagen considera generar un certificado que contiene una llave pública y una privada.
Luego, se firma el certificado con un certificado raíz de una Autoridad de certificados (dando la llave pública por una solicitud de firmado .csr). Finalmente, se firma el certificado, emitido y exportado en formato P12, para ser usado con su contraseña cuando se va a configurar una comunicación de confianza como SAML 2.0.
Prerrequisitos
El principal prerrequisito es instalar el SDK de su preferencia que va a utilizar para generar certificados auto-firmados. En este artículo se guiarán los pasos a aplicar para usar OpenSSL como el SDK para este propósito.
Para ello, descargue el instalador apropiado de OpenSSL de https://slproweb.com/products/Win32OpenSSL.html, donde encontrará los instaladores de 64 y 32 bits, escoja el adecuado de acuerdo a la arquitectura de su sistema.
Para el Sistema Operativo Windows, la instalación es asistida, y se recomienda seguir los pasos por defecto. Guarde las configuraciones indicando copiar las DLLs de OpenSSL en el directorio de binarios de OpenSSL:
Al terminar la instalación exitosamente, debe poder ver el archivo ejecutable openssl.exe (en el caso de windows), además del archivo de configuración openssl.cfg, en el directorio de binarios o ubicación indicada en la instalación:
Se recomienda que añada OpenSSL a sus variables de ambiente del sistema, de manera que pueda correr sus ejecutables sin preocuparse de las rutas.
Para ello, edite la variable de ruta Path:
Y asegúrese de añadir la ubicación anterior (directorio binario de OpenSSL) a sus rutas registradas:
Finalmente, dé clic en OK y guarde los cambios cuando cierre las ventanas (cualquier línea de comandos, ventanas de variables de ambiente, etc).
Con los pasos indicados en este artículo, OpenSSL se empleará usando línea de comandos.
En caso de que esté interesado en aprender otras opciones y para obtener información completa sobre las opciones de comandos de OpenSSL, refiérase a su documentación oficial en https://www.openssl.org/docs/man1.0.2/apps/openssl-req.html.sl.org/docs/man1.0.2/apps/openssl-req.html.
Antes de empezar
El objetivo de estos pasos es emitir dos certificados diferentes: uno para la firma de mensajes y otro para el cifrado.
Se recomienda que cree una carpeta para almacenar los certificados a emitir dentro de los siguientes pasos, para que pueda ubicarlos fácilmente.
A esta ruta se le referirá como <CERT_DIR>.
La siguiente imagen de ejemplo, muestra un directorio creado como C:\Root\MyCerts:
Lo que debe hacer
Al emitir un certificado auto-firmado, se llevan a cabo los siguiente pasos enumerados:
1.Crear una solicitud de firma de certificados (CSR por sus siglas en inglés).
2.Firmar la petición.
3.Exportar las llaves pública y privada bajo un formato P12.
Procedimiento
1. Crear una solicitud de firma de certificados (CSR)
Necesitará emitir una solicitud de firma de certificados antes de emitir el certificado final, creando tanto la llave pública como la privada.
Considere que los comandos indicados pueden mostrarse en mas de una línea con fines de presentación.
Para los comandos mostrados abajo que son largos, asegúrese de eliminar cualquier fin de línea entre los parámetros.
1.1. Abra una línea de comandos y navegue hasta el directorio <CERT_DIR> creado previamente.
1.2. Ejecute el siguiente comando para crear la solicitud de firma de certificados, para el certificado que se usará para firmar aserciones (confirmaciones):
openssl req -newkey rsa:2048 -subj "[certificate_details]" -nodes -sha256 -keyout [key_name].key -out [csr_name].csr
Considere reemplazar:
•[certificate_details]: El identificador y detalles que se muestran del certificado.
Dicha información debe tener el siguiente formato: /C=[CO]/ST=[ST]/L=[city]/O=[org]/OU=[unit]/CN=[display_name]/
Remplace [CO] por el código de 2 dígitos de su país,[ST] por el código de 2 dígitos de su estado, [city] por la localidad o ciudad, [org] por el nombre de su organización, [unit] por la unidad organizacional, y [display_name] por el identificador del certificado.
Para claridad y conveniencia, se sugiere, se sugiere que [display_name] incluya la palabra Sign en alguna parte.
•[key_name]: El nombre para el archivo que se generará conteniendo la llave privada.
Para claridad y conveniencia, se sugiere que incluya la palabra Sign en alguna parte.
•[csr_name]: El nombre del archivo que se generará conteniendo la solicitud de firma de certificado con la llave pública.
Para claridad y conveniencia, se sugiere que incluya la palabra Sign en alguna parte.
Una vez que el comando haya ejecutado satisfactoriamente, los dos archivos de salida (.key y .csr) quedarán en su directorio <CERT_DIR>:
1.3. Repita el paso anterior si desea encriptar aserciones.
Recuerde que encriptar las aserciones es opcional y se debe hacer siempre y cuando su IdP lo soporte.
Si elige hacerlo, entonces corra el mismo comando anterior:
openssl req -newkey rsa:2048 -subj "[certificate_details]" -nodes -sha256 -keyout [key_name].key -out [csr_name].csr
Esta vez, especifique un [key_name] diferente, , al igual que el[csr_name](en comparación al paso anterior), de tal manera que no sean sobrescritos.
Para claridad y conveniencia, se sugiere que dichos nombres incluyan la palabra Encrypt en alguna parte.
Similarmente, y con la información de[certificate_details], el [display_name] debe ser diferente para cada certificado generado.
Una vaz que el comando haya ejecutado satisfactoriamente, los dos archivos de salida (.key y .csr) son generados en su directorio <CERT_DIR>:
2. Firmar la solicitud
Para firmar la solicitud, usted requiere un Autoridad de Certificados (CA por sus siglas en inglés), y es mejor que utilice una que ya se haya usado para su organización.
Si va a utilizar una CA existente en su organización, necesitará copiar sus archivos .cer y .key en su directorio <CERT_DIR>, y continuar directamente en el paso 2.2.
2.1. En caso de que no tenga una CA existente, entonces puede usar una local siguiendo el comando:
openssl req -new -newkey rsa:2048 -days [validity] -extensions v3_ca -subj "[certificate_details]"
-nodes -x509 -sha256 -set_serial 0 -keyout [root_key].key -out [root_cer].cer
Considere reemplazar:
•[validity]: Número de días para certificar el certificado. Por ejemplo, 3650 aplica para 10 años. Usar un valor alto como 3650 es mejor para evitar cualquier sobrecarga administrativa relacionada con el proceso de generar certificados periódicamente. Sin embargo, es importante reconocer que esta decisión depende de usted, de acuerdo a sus políticas corporativas y que necesitará asegurar que dichos certificados son mantenidos, pues su autenticación depende de ello.
•[certificate_details]: El identificador y detalles del certificado.
Dicha información debe tener el siguiente formato: /C=[CO]/ST=[ST]/L=[city]/O=[org]/OU=[unit]/CN=[display_name]/
Remplace [CO] por el código de 2 dígitos de su país, [ST] por el código de 2 dígitos de su estado, [city] por su localidad o ciudad, [org] por el nombre de su organización, [unit] por su unidad organizacional, y[display_name] por el identificador del certificado.
For clarity and convenience, we suggest that the [display_name] includes the word Root somewhere.
•[root_key]: El nombre para el archivo que se generará con la llave privada.
Para claridad y conveniencia, se sugiere que incluya la palabra Root en alguna parte.
•[root_cer]: El nombre para el archivo del certificado que se generará con la llave pública.
Para claridad y conveniencia, se sugiere que incluya la palabra Root en alguna parte.
Cuando el comando haya ejecutado satisfactoriamente, los dos archivos de salida (.key y .cer) se generarán en su directorio <CERT_DIR>:
2.2. Ejecute el siguiente comando para firmar la solicitud de firma de certificado para las aserciones:
openssl x509 -req -sha256 -CAcreateserial -in [csr_name].csr -days [validity]
-CA [root_cer].cer -CAkey [root_key].key -out [cer_name].cer
Considere reemplazar:
•[validity]: Número de días para certificar el certificado. Por ejemplo, 3650 aplica para 10 años. Usar un valor alto como 3650 es mejor para evitar cualquier sobrecarga administrativa relacionada con el proceso de generar certificados periódicamente. Sin embargo, es importante reconocer que esta decisión depende de usted, de acuerdo a sus políticas corporativas y que necesitará asegurar que dichos certificados son mantenidos, pues su autenticación depende de ello.
•[root_key]: El nombre del archivo que contendrá la llave privada de la CA.
Debe coincidir con el nombre definido en el paso anterior en caso de que haya generado una CA; o el nombre del archivo copiado al directorio <CERT_DIR> en caso de que este usando una CA existente.
•[root_cer]: El nombre del archivo de certificado que contendrá la llave pública de la CA.
Debe coincidir con el nombre definido en el paso anterior en caso de que haya generado una CA; o con el nombre del archivo copiado en el directorio <CERT_DIR> en caso de que esté utilizando uno existente.
•[csr_name]: Nombre del archivo de solicitud de firma de certificado, como se definió en el paso 1.2.
Recuerde que es obligatorio hacer esto para el certificado involucrado en la firma de aserciones.
•[cer_name]: Nombre del archivo del certificado final que será generado con la llave pública.
Para claridad y conveniencia, se sugiere que incluya la palabra Sign en alguna parte.
Note que el asunto desplegará los detalles y el identificador del certificado generado primero.
Cuando haya terminado el comando exitosamente, un archivo .cer de salida se mostrará en su directorio <CERT_DIR>:
2.3. Repita los pasos anteriores si va a encriptar aserciones y realizó los pasos indicados en la sección 1.3.
Si decide hacer esto, ejecute el mismo comando anterior:
openssl x509 -req -sha256 -CAcreateserial -in [csr_name].csr -days [validity]
-CA [root_cer].cer -CAkey [root_key].key -out [cer_name].cer
Considere reemplazar:
•[validity]: Número de días para certificar el certificado. Por ejemplo, 3650 aplica para 10 años. Usar un valor alto como 3650 es mejor para evitar cualquier sobrecarga administrativa relacionada con el proceso de generar certificados periódicamente. Sin embargo, es importante reconocer que esta decisión depende de usted, de acuerdo a sus políticas corporativas y que necesitará asegurar que dichos certificados son mantenidos, pues su autenticación depende de ello.
•[root_key]: El nombre del archivo que contendrá la llave privada de la CA.
Debe coincidir con el nombre definido en el paso anterior en caso de que haya generado una CA; o el nombre del archivo copiado al directorio <CERT_DIR> en caso de que este usando una CA existente.
•[root_cer]: El nombre del archivo de certificado que contendrá la llave pública de la CA.
Debe coincidir con el nombre definido en el paso anterior en caso de que haya generado una CA; o con el nombre del archivo copiado en el directorio <CERT_DIR> en caso de que esté utilizando uno existente.
•[csr_name]: Nombre del archivo de solicitud de firma de certificado, como se definió en el paso 1.3.
Recuerde que es obligatorio hacer esto para el certificado involucrado en la firma de aserciones.
•[cer_name]: Nombre del archivo del certificado final que será generado con la llave pública.
Para claridad y conveniencia, se sugiere que incluya la palabra Encrypt en alguna parte.
Note que se mostrarán los detalles e identificador del certificado generado primero, que serán diferentes a los del paso 2.2.
Cuando el comando haya ejecutado exitosamente, un archivo .cer de salida se muestra en su directorio <CERT_DIR>:
3. Exportar las llaves privada y pública en formato P12
Como último paso, usted requiere un archivo P12 que contenga tanto la llave pública como privada.
3.1. Ejecute el siguiente comando para hacerlo, primero para el certificado usado para firmar las aserciones:
openssl pkcs12 -export -macalg SHA1 -keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES -in [cert_name].cer -inkey [key_name].key -out [p12_name].p12 -CSP "Microsoft Enhanced RSA and AES Cryptographic Provider"
Considere reemplazar:
•[cert_name]: Nombre del archivo de certificado, como se definió y generó en el paso 2.3.
•[key_name]: Nombre del archivo de la llave privada, como se definió y generó en el paso 1.3.
•[p12_name]: Nombre del archivo P12 que se generará.
Para claridad y conveniencia, se sugiere que incluya la palabra Sign en alguna parte.
Note que en este punto, se le pedirá ingresar una contraseña para el archivo P12 (y su respectiva confirmación).
Asegúrese de copiar y recordar dicha contraseña (y guardarla de manera segura), dado que se necesitará para los pasos siguientes de configuración en Bizagi.
Una vez que el comando haya ejecutado exitosamente, un archivo .p12 será generado en su directorio <CERT_DIR>:
3.2. Repita los mismos pasos previos en caso de que desee encriptar aserciones, esto es, si realizó las instrucciones del paso 1.3.
Si lo está realizando, entonces ejecute el mismo comando anterior:
openssl pkcs12 -export -macalg SHA1 -keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES -in [cert_name].cer -inkey [key_name].key -out [p12_name].p12 -CSP "Microsoft Enhanced RSA and AES Cryptographic Provider"
Considere reemplazar:
•[cert_name]: Nombre del archivo de certificado, como se definió y generó en el paso 2.3.
•[key_name]: Nombre del archivo de la llave privada, como se definió y generó en el paso 1.3.
•[p12_name]: Nombre del archivo P12 que se generará.
Para claridad y conveniencia, se sugiere que incluya la palabra Encrypt en alguna parte.
Note que en este punto, se le pedirá definir una contraseña para el archivo P12 (y su respectiva confirmación).
Asegúrese de copiar y recordar dicha contraseña (y de guardarla de manera segura), dado que la necesitará para los pasos de configuración en Bizagi.
Cuando el comando haya ejecutado exitosamente, un archivo .p12 será generado en su directorio <CERT_DIR>:
Punto de control
En este punto, usted puede decidir verificar que el archivo .p12 este bien formado y que contiene todo lo que necesita.
Recuerde que debe tener un archivo .p12, o dos, dependiendo si decidió encriptar las aserciones o no.
1. Para esto, ejecute el siguiente comando para verificar el archivo .p12 a utilizar para firmar las aserciones:
openssl pkcs12 -info -nodes -in [p12_name].p12
Considere reemplazar:
•[p12_name]: Nombre del archivo P12 como se definió y generó en el paso 3.1.
Note que en este punto, se le pedirá ingresar la contraseña del archivo P12 (como se definió en la sección 3.1).
Aparte de ver los errores en el comando, verifique:
•Que la contraseña que definió es correcta.
•Que se muestran las llaves pública y privada.
•Que el asunto muestra los detalles precisamente como se definieron al generar el certificado.
•Que el emisor muestra los detalles precisos de la CA utilizada para firmar el certificado.
•Otros, como el algoritmo empleado.
2. Si va a encriptar las aserciones (esto es, si llevó a cabo las instrucciones del paso 1.3), entonces debe repetir el mismo paso anterior pero para el archivo .p12 correspondiente.
Para ello, ejecute el siguiente comando:
openssl pkcs12 -info -nodes -in [p12_name].p12
Considere reemplazar:
•[p12_name]:Nombre del archivo P12 como se definió y generó en el paso 3.2.
Note que en este punto, se le pedirá entrar la contraseña del archivo P12 (como se definió en el paso 3.2).
Last Updated 7/11/2023 8:01:22 AM