Certificates
What is certificate-based Authentication?
Certificate-based authentication is a method of authentication in which a digital certificate is used to verify the identity of a user, device, or application.
Digital certificates are issued by a trusted third party called a Certificate Authority (CA). They contain information about the identity of the user or device, as well as a public key that can be used to encrypt and decrypt messages.
To use certificate-based authentication, a user or device must first obtain a digital certificate from a trusted CA. The certificate is then installed on the user's device or in the application. When the user or device attempts to access a secure resource, the certificate is presented to the server. The server verifies the certificate by checking its validity, authenticity, and revocation status. If the certificate is valid, the server grants access to the resource.
Certificate-based authentication provides a high level of security because it uses digital certificates, which are difficult to forge or manipulate. It is commonly used in enterprise environments to authenticate users and devices, as well as in secure online transactions such as e-commerce and online banking.
What is the difference between certificates and passwords?
Certificates and passwords are two different authentication mechanisms used to verify the identity of a user or system. Password-based authentication is the traditional method of authentication where a user enters a username and password to gain access to a resource. The server compares the entered credentials to the stored credentials and grants access if they match. Certificates, on the other hand, are digital documents that contain information about the identity of a user or system and are used to authenticate the user or system. Certificates are issued by a trusted third party called a Certificate Authority (CA) and are used to verify the identity of the entity that presents them. Certificates are based on public key cryptography, where a private key is used to sign a certificate and a public key is used to verify the signature.
Another difference between certificates and passwords is that certificates can be used for machine-to-machine authentication, while passwords are typically used for user authentication. This makes certificates ideal for securing APIs, IoT devices, and other machine-to-machine connections.
In summary, certificates and passwords are two different authentication mechanisms used to verify the identity of a user or system. Certificates are more secure than passwords and can be used for machine-to-machine authentication, while passwords are typically used for user authentication. Certificates are based on public key cryptography, which is considered very secure, and are issued by a trusted third party called a Certificate Authority.
How can I create a new root certificate?
The basis for certificate-based authentication is a root certificate from which all personal certificates can be created. Existing certificates can also be used for logging in with smartcards.
However, if a new certificate has to be created, this can be done by using the OpenSSL tool:
openssl genrsa -out ca.key 4096
openssl req -new -x509 -days 18260 -key ca.key -out ca.crt
The result is the new certificate ca.crt which can be used to create or sign the personal login certificates for users.
This root certificate must be imported for certificate-based login in Identity Provider like SAP.
How can I create personal certificates to log in?
As with root certificates, personal certificates from other processes can also be reused. However, it must be verified that these were created in the correct format and can be accepted by the identity provider.
This tutorial shows an example of how the certificates can be created. There are many external tools to automate or improve this process. It is important that the resulting certificates are accepted by the Identity Provider.
If new certificates need to be created, the tool OpenSSL can be used.
The next steps require the root certificate ca.crt created in the previous section. This must be installed on the computer on which the personal certificates will be created.
This can be done by double clicking on the file and selecting Install certificate... It is important that the folder Trusted Root Certification Authorities is selected as the Certificate Store.
The next step is to create two local files per personal certificate:
- .conf file
- .ext file
Example of the content of the .conf file (johndoe.conf):
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = DE
ST = Bayern
L = Wuerzburg
O = Flexus AG
OU = IT
CN = johndoe@mycompany.net
[v3_req]
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = email:johndoe@mycompany.net
Example of the contents of the .ext file (johndoe.ext):
keyUsage = digitalSignature, nonRepudiation
subjectAltName = email:johndoe@mycompany.net
If these two files are available locally, the personal certificate can be created with OpenSSL:
openssl genrsa -out johndoe.key 4096
openssl req -new -days 825 -key johndoe.key -out johndoe.csr -config johndoe.conf
openssl x509 -req -days 730 -in johndoe.csr -CA ../ca.crt -CAkey ../ca.key -set_serial 01 -out johndoe.crt
openssl x509 -req -days 730 -sha512 -in johndoe.csr -CA ../ca.crt -CAkey ../ca.key -out johndoe.crt -extfile johndoe.ext -CAcreateserial
openssl pkcs12 -export -out johndoe.p12 -inkey johndoe.key -in johndoe.crt -chain -CAfile ../ca.crt -passout pass:mysupersecretpassword
The result is the new user specific certificate johndoe.p12 which can be imported in the Identitiy Provider like SAP or Microsoft Azure AD. The password should be noted down, as it is needed when the certificates are written to a SmartCard and then decrypted in TheFlex.
It is important to check that the certificate chain to the root certificate is present for this certificate. By double-clicking on the certificate, the root certificate should be visible in a tree structure. If this is not the case, a common error is that the root certificate was not or incorrectly installed on the computer.