The SAML authentication protocol requires that you manage certificates. There are two usages for certificates: To sign the SAML assertions and to encrypt the assertions. This section gives some considerations related to the management of these certificates.
Considerations about certificates
You can either use purchased certificates (if you already have them), signed certificates by a certifying authority (CA), or you can use self-signed certificates. If you use self-signed certificates it is important that the certificate is created with the following requirements:
•The certificate must be in .P12 or .PFX file format. This format contains both the private and the public key and needs a passphrase to open.
•The password for the certificate file, as defined by you when you exported the public and private keys.
•Give the certificate the maximum expiration date allowed in your organization.
•The following parameters are recommended, though, they are not mandatory:
▪Common Name or fully-qualified domain name (CN), for example, www.example.com.
▪Organization name (O)
▪Country code (C)
▪City code (L)
oSubject Alternative Name (SAN). For example, DNS name = *mycompany.com
Because certificates have expiration dates, it is very important that you keep track of the due date. Otherwise, if the certificate expires without renewing it, users will NOT be able to access the web portal using the SAML identity provider using that certificate.
About the P12 format
The P12 or PFX format is an encrypted file that encompasses both the private and public keys. When generating these certificates you must include a password (passphrase) so this password is used to decrypt its content.
This certificate is used to sign SAML2 assertions, therefore, private and public keys will be used to encrypt outgoing messages and decrypt incoming messages.
You must use P12 files for two purposes:
•Signing SAML2 assertions (mandatory usage)
•Encrypt messages (optional usage)
How to generate self signed certificates
Refer to Issuing self-signed certificates to learn how to create certificates.
Is the certificate for HTTPS/TLS purposes?
No, this certificate is only to sign and encrypt SAML2 assertions. In our cloud services, HTTPS/TLS is already in place.
Does having a certificate represents an extra cost?
No, you can rely on local CA or self-signed certificates.
Is using a self-signed certificate less secure?
Not for signing purposes because this certificate is not exposed to the public, hence, it does not represent a vulnerability. It is only used for signing messages at the application level based on the SAML2 logic.
Does use a certificate depend on the Identity Provider?
No, You will always need a certificate and uploaded in Bizagi's Customer Portal when configuring ANY Identity Provider.