Nexus Documentation
CURL vulnerability information (CVE-2023-38545) - Nexus awareness advisory on Microsoft's update KB5014754

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

This article describes the service settings for Nexus GO Workforce.

Certificates

Certificates provided in the service are created from certificate templates based on years of best practice.
How the certificates from the service are used is the customer's responsibility. Nexus provides examples of use-cases, and do not configure such use cases in the customer's environment.

 Validity

Validity of certificates is decided during the initial contact with Nexus sales.
The default validity of certificates (unless otherwise specified) is the following:

  • Root certificate: 30 years
  • Intermediate(s) certificate: 15 years

  • End-user Authentication: 3 years
  • End-user Signing (document): 3 years
 Certificate revocation checks
 CRL

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.

 OCSP validation

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.

 Troubleshooting
  • Unable to validate smart card logon?
  • Certificate validation failure locally?

You can validate the certificate outside of your application as an example via the following tools:

 Certutil (Windows)

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:

    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."
 OpenSSL (Windows/Unix)
  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:

    OCSP validation
    openssl ocsp -issuer chain.pem -cert certificate.pem -text -url http://ocsp.go.nexusgroup.com
    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.

Services authentication

This section covers what is unique when doing logon to the GO services portals, such as a the operator portal and the self-service portal. A combination of OCSP and CRL validation is used for the logon to the services, a fresh CRL is fetched every 15 minutes.

 Authentication methods

Each customer has a unique set of authentication methods depending on what kind of service that has been requested. This section covers the authentication methods used, but keep in mind that it is customer unique which authentication methods that are available.

These are the default settings for each authentication method. Naming convention might also have slight differences, but the concept remains the same when it comes to availability of a method.

 Smart Card

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.

 Smart Card Desktop

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.

 Smart Card NFC

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.

 Mobile ID

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.

 SAML Federations

SAML 2.0 federations are possible towards the GO Workforce service. A strong 2FA policy is applied to be able to logon to the services to protect the environments and the customers.

 IDP - Identity Provider

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)

SAML Auth context
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

Related information

  • No labels

Copyright 2024 Technology Nexus Secured Business Solutions AB. All rights reserved.
Contact Nexus | https://www.nexusgroup.com | Disclaimer | Terms & Conditions