You are viewing the documentation for a prerelease version.

System requirements and configurations

Some additional configurations is required depending on purpose of using the service.

Microsoft Active Directory Certificate Services

The Microsoft Active Directory Certificate Services (MSCA) can be used in several ways depending on purpose. The most common way is using the MSCA-service to issue certificates against users for certificate login for e.g. Microsoft Windows clients. Then the MSCA-service needs to be configured this way.

Another purpose is to let the MSCA-service issue certiifcate against servers, or SSL/TLS certificates. Then the MSCA-service needs to be configured in another way.

Another purpose is to let the MSCA-service issue subordinated CA certificates. Then the MSCA-service needs to be configured in another way.

The MSCA-service has two different structures when install/setup the CA in the Microsoft environment:

Enterprise CA

The Enterprise CA setup uses different kind of templates depending on the purpose of the certificate to be issued. This structure is the most common way using the portal to issue certificates.

StandAlone CA

The StandAlone CA setup does not have any templates, instead the CA will issue certificates from the certificate request as it is and acts as a stamp. This structure can be used when issue static certificates with static information like web servers or subordinated CA-services. This structure is not recommended for issuing user certificates because user certificates has dynamic information in the certificate.

The MSCA-service has two different types of request handling for issuing the certificates:

Pending

The certificate request is set to pending and an administrator explicit need to issue the certificate.

Auto

The certificate request will be handled by an already configured template of the MSCA and automatically issue the certificate.

The Net iD Portal has three different types of request handling to match some of the configurated types of the MSCA-environment:

Modifier

This type will use MSCA for dynamic content of the certificate for special purposes. An example is to issue user certificates with special added extensions or other certificates that is not handled by a domain controller. The MSCA needs to be configured with request handling: Pending. However, this requires a higher level of permissions against the MSCA-service. It’s recommended to install MSCA typed as Enterprise CA for this purpose.

The certificate request (PKCS#10) will be sent by the portal to the MSCA. MSCA will set the issuing state to pending. The portal will re- issue the certificate against the MSCA acting administrator approval and the MSCA will issue the certificate and send the issued certificate back to the portal.

Stamp

This type will use MSCA for static content of the certificate. The MCSA need to be configured with request handling: Auto.

The certificate request (PKCS#10) will be sent by the portal to the MSCA. MSCA will issue the certificate and send the issued certificate back to the portal.

AgentSigner

This type will use MSCA to issue certificate with an additional signing certificate that is specified in the template of the environment. The MSCA needs to be installed as Enterprise CA with the request handling:

Auto. This is recommended for issuing user certificates handled by the domain controller. This type can also be used to issue computer/server certificates that is handled by the domain controller.

The certificate request (PKCS#10) will be combined with information of the entity object (user or computer of the domain controller) into a CMC-request. The CMC-request will be be sent by the portal to the MSCA. MSCA will verify the signature of the CMC-request and information of the user/computer, issue the certificate and send the issued certificate back to the portal.

Typical examples of purposes:

  • User certificates (handled by domain controller) MSCA: Structure: Enterprise CA

MSCA: Request handling: Auto Portal: Issuance type: AgentSigner

  • User certificates (not handled by domain controller) MSCA: Structure: Enterprise CA

MSCA: Request handling: Pending Portal: Issuance type: Modifier

  • Computer/server certificates (handled by domain controller) MSCA: Structure: Enterprise CA

MSCA: Request handling: Auto Portal: Issuance type: AgentSigner

  • Computer/server certificates (not handled by domain controller) MSCA: Structure: StandAlone CA

MSCA: Request handling: Auto Portal: Issuance type: Stamp

  • EndEntity certificates (any) (not handled by domain controller) MSCA: Structure: Enterprise CA

MSCA: Request handling: Pending Portal: Issuance type: Modifier

  • Web certificates (not handled by domain controller)

Extended Validation Certificate (EV)

An EV certificate is the highest level of SSL certificates. All SSL certificates – Extended Validation (EV), Organization Validated (OV), and Domain Validated (DV) – provides encryption and data integrity. However, they vary in how strict the process is to verify the identity of the website owner. An EV certificate provides the highest level of digital identity assurance by verifying the legal identity of a website owner.

MSCA: Structure: Enterprise CA MSCA: Request handling: Pending Portal: Issuance type: Modifier

Transparency Certificate (CT)

A feature that allows a certificate to be issued by a CA, while also enabling a compliant operator to monitor and audit a publicly available certificate transparency log to which the certificates are also sent.

MSCA: Structure: Enterprise CA** MSCA: Request handling: Pending Portal: Issuance type: Modifier

Its possible to issue CT certificate against a computer/server if handled by a domain controller for internal use.

MSCA: Structure: Enterprise CA** MSCA: Request handling: Auto Portal: Issuance type: AgentSigner

  • The MSCA-service needs further configuration to enable CT of the CA (see information below). The EJBCA also support CT but it’s required to use the Enterprise version of the EJBCA.

Microsoft Active Directory Certificate Services: Enable CT

To enable Certificate Transparency (CT) in MSCA-service the following steps is required:

  • Create a registry value that is named CertificateTransparencyFlags, and then type REG_DWORD under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\ Configuration\<CA Name>.

  • Enable the 0x1 bit on the CertificateTransparencyFlags (value 0x1). By default, this feature is disabled.

  • Clearing out the 0x1 bit on the CertificateTransparencyFlags (value 0x0) disables the feature. The new CT requests will be rejected, and mid-hop requests will not be issued.

  • Set the MaxSCTListSize (REG_DWORD) to customize the max SCTList accepted, in bytes. The default is 1024 bytes.

  • Set the CTInformationExtensionOid (REG_SZ) to customize the OID in the issued certificate that contains the binary data that’s returned to the CA in the second hop. (This could be the SCTList if CT v1, or the TransItemList if CT v2, or anything else.)

  • Set the 0x2 bit on the CertificateTransparencyFlags REG_DWORD to disable validation of the binary data that’s returned to the CA in the second hop. (Use this if you want to use a TransItemList or other custom binary data.) Otherwise, the CA performs basic CT v1 SCTList syntax validation.

  • It’s recommended to use a separated instance of the MSCA-service for these kind of certificates.