Certificate purchasing

SAML POST binding requirements

Compatible Certificate Authorities

In response to requests from organisations, RealMe® has removed the restriction on permitted Certificate Authorities for SAML POST binding signing and encryption. In the production and ITE environments, RealMe will trust certificates that organisations purchase from their preferred provider. Certificates do not need to be the more costly Extended Validation (EV) type. Self-signed certificates are not acceptable.

Certificate duration

The default duration requirement for certificates was previously 3 years, but from 2018 Certificate Authorities are restricting the lifetime, so this is now reduced to 2 years, with DIA occasionally permitting shorter durations in ITE where justified. RealMe Operations will liaise with the agency about certificate expiry.

Certificate reuse

  • Separate certificates are required for the RealMe Production and ITE environments, but a certificate can be used for multiple agency environments connected to ITE (e.g. dev, systest, uat, etc.).
  • Within a RealMe environment, a certificate may be reused across more than one online service to validate the same agency – or more specifically the same privacy domain.

Certificate common name and bit length

The CSR for the SP certificate must comply with the common name requirements and have a minimum bit length of 2048.

The RealMe requirement is that integrating organisations should follow the stated naming conventions. If there is a significant difficulty with satisfying the requirements, then this can be discussed with the RealMe integration team. The naming rules have changed to provide greater flexibility for integrating organisations.

  • The certificate name for RealMe use should only contain permitted characters: alphanumeric characters and the special characters dot, hypen, colon and forward slash.
  • The certificate name must be globally unique across RealMe services.

The certificate name for the SAML POST binding SP signing and encryption certificate should conform to the following pattern:

{environment}.{organisation domain [with service and/or privacy domain]}

where:

  • environment values for production can be “prod” (preferred), “production” or null (implying production)
  • environment values for non-production can be the RealMe environment name “ite” (preferred) or any agency descriptor such as “testing”, “pre-prod”, “qa”, “sysdev”, etc.
  • organisation domain is a globally unique identifier using a domain style format such as agency.govt.nz.
  • service or privacy domain can be appended to organisation domain in a url format, RealMe entityID format, or similar construct – for example:
       service1.agency.govt.nz
       agency.govt.nz/customers/service2
       service3.function.agency.govt.nz
       organisation.co.nz/services

A valid example is:

ite.example-ministry.govt.nz/customers/benefit-apply

The organisation domain should generally resemble the organisation's primary domain name so that RealMe Operations can easily link the certificate with the responsible agency, but note that the value is not tested with a DNS lookup.

If a certificate will be shared across multiple online services in the same privacy domain, then the certificate name should appropriately reflect this.

SAML Artifact binding and RCMS certificates 

For the Artifact binding mutual SSL certificate and applicable web services (including RCMS), RealMe can only process certificates from three Certificate Authorities: RapidSSL, Thawte and Verisign.

The certificate name for SAML Artifact binding back-channel or applicable RealMe web services (e.g. RCMS) can follow the legacy certificate name pattern if already integrated or use the following pattern with “mutual-ssl” in the certificate name to distinguish the back-channel certificate:

{environment}.mutual-ssl.{organisation domain [with service and/or privacy domain]}

 

Subscribe