CRL (Certificate Revocation List), is a list with all certificates that are currently revoked. If a certificate does not exist in this list, a system generally assumes that it is valid, based on the data on the certificate. The CRL is a file, and it gets automatically downloaded locally into the system every time it is fetched. The frequency of fetching the CRL is system based, and is not controlled by the service.

Validity: 7 days

Validity margin: 3 days

Reason for the 10 day validity, is to allow computers which are not always connected to the internet still be able to validate on the cached CRL on the computer. If you lower the validity, you might experience issues with computers which does not always have access to internet frequently.

Unlike CRL, OCSP (Online Certificate Status Protocol) is an online version, which responds immediately if a certificate is valid or not with different states. It does not rely on cache functionality. This should be used as first priority verification, if possible, due to the fact that it will respond much faster than a CRL.

Read more here: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/certutil

One of the benefits of using Certutil is that it is also the tool that can clear your CDP/AIA cache on the Windows computer.

More info about CRL cache and how to clear it can be found here.

1. Open the Certutil GUI on Windows by running in cmd the following command:
   
   

   Code Block
   title Certutil GUI
   certutil -url http://

   
   

2. Select the certificate you want to validate.

• • Certs (from AIA) "This validates the presence of the CA chain on the computer, and validates it towards the OCSP."
  • CRLs (from CDP) "This validates the certificate selected towards the CRL endpoint, checking if it exists in the revocation list or not."
  • OCSP (from AIA) "This validates the certificate select towards the OCSP endpoint, checking if it is revoked or not."

1. For OpenSSL, the certificate you want to test must be available on file, along with the root and intermediate CA certificates.

2. Then run the following command:

   Code Block
   language powershell title OCSP validation
   openssl ocsp -issuer chain.pem -cert certificate.pem -text -url http://ocsp.go.nexusgroup.com

   
   

   Code Block
   language powershell title CRL validation
   openssl verify -crl_check -CAfile chain.pem certificate.pem

   chain.pem should contain the root and intermediate CA's, this is customer specific.
   certificate.pem is the actual certificate you want to test towards OCSP and CRL.

This authentication method is certificate-based, and it also uses the native functions of the browser to authentication via TLS/SSL. This method usually caches information in the browser, such as PIN and logon information.

This method can be used on all devices allowing certificate authentication where you have a certificate available for authentication.

This authentication method is certificate-based, and it requires the Nexus Smart ID Desktop App to be on installed on the computer which you are trying to authenticate on. This does not (unlike the TLS/SSL option) cache the PIN.

Keep in mind that the Nexus Smart ID Desktop App is currently only available for Windows computers.

This authentication method is certificate-based, but requires an NFC compatible device with the Nexus Smart ID Mobile App installed on it. Nexus Smart ID Mobile App is available on Android Playstore and iOS Appstore.

This also requires a NFC encoded Smart Card to be able to be used for logon, and is generally only present for the self-service portal.

This authentication method is purely mobile-based, and requires a permanent Mobile ID to be present on a mobile device via the Nexus Smart ID Mobile App.

This requires user input, such as an email.

Nexus is able to act as Identity Provider in a SAML federation setup. A SAML 2.0 metadata is provided as part of the onboarding. This SAML metadata can then be added to a customer SP (Service Provider) and from there, the customer is able to use the Authentication method in the services as an option for their internal applications.

Nexus configures all authentication method with SAML authentication context. SPs that support being able to provide SAML authentication context, can then point towards a specific IDP authentication method in the services. Nexus GO Services team is not responsible for configuring this in the customer's environments.

Standard authentication context looks like this (customer unique number)

urn:oasis:names:tc:SAML:2.0:ac:classes:SmartCardC99
urn:oasis:names:tc:SAML:2.0:ac:classes:SCDC99
urn:oasis:names:tc:SAML:2.0:ac:classes:mobileIdC99
urn:oasis:names:tc:SAML:2.0:ac:classes:MobileNFCC99