Securing digital certificates

A digital certificate is a set of electronic data that uniquely identifies an organization. The certificate contains a public key for the organization, and is digitally signed by a trusted party to bind the public key to the organization.

Other information in the certificate specifies how the key is used and the time period for which it is valid. In AS4 Microservice, you can use certificate authority certificates, private/public key certificates, and trading partner certificates.

The digital certificate establishes an association between the identity of the subject (owning organization) and a public key. The private key that is paired with the public key in the certificate is stored separately. Digital certificates provide protection against impersonation because a digital certificate binds a public key to its owner. Digital certificates are also known as public key certificates because they provide assurance about the ownership of a public key. A digital certificate contains the public key for an organization and is a statement that the public key belongs to that entity.

Important:

Digital certificates do not contain your private key. You must keep your private key secret. Typically, it never leaves the device on which it was created.

If public keys are sent directly by their owner to another organization, the message can be intercepted and the public key can be substituted by a malicious third party. The solution is to exchange public keys through a trusted third party to assure both organizations that the public key really belongs to the partner with which you are communicating. Instead of sending your public key directly to your partner, you ask the trusted third party to incorporate it into a digital certificate. The trusted third party that issues a digital certificate is called a certificate authority (CA).

Note: Configure root and intermediate certificates for your primary organization.

You can use a private/public key pair certificate to sign outbound messages, and the message is submitted to the message receiver with a user ID. The user ID determines the mechanism by which users are identified. By default, the user ID is determined by:

If a user name token header is found, the user name is considered to be the user ID.
If a signature header is found, the embedded certificate is used as an identifier (by default, the issuer plus the serial number is used as the user ID).
If both the signature header and the user name token are present, user name is accorded a higher priority.

If you have custom X.509 extensions and subject attributes in the certificate that is used in your system as the unique identifier for the user, you can define two system properties to configure the user ID:

USERID_CERT_OIDS: This property contains a comma-separated list of object identifiers (OIDs) that represent the certificate extensions (for example, the OID 1.2.36.1.333.1 represents the ABN in an Auskey certificate). The extension values are extracted from the certificate sequentially, in the order that is specified in this property.
USERID_CERT_SUBJECT_ATTRIBUTES: This property contains a comma-separated list of the attribute names for the certificate subject.

The values for these subject attributes are extracted from the certificate. The values that are obtained for the OIDs and Subject Attributes are then concatenated with a delimiter (|) to create a unique string that represents the user ID. This user ID is sent to the business application as the user ID in the business document object. In pull scenarios, the user ID is used to determine which message is sent in the Pull Response.

After you add the certificate, you select it in the conformance policy (for AS4) to enable HTTPS client authentication, message signing, and signature verification. The information for the private/public key pair certificate is provided through the key identifier.

A trading partner certificate is received from your partner and added to the system for that specific partner. The trading partner certificate verifies the signature of an incoming message (either a request or response message, depending on the direction) from that partner. You can select the certificate to use for partner authentication in the exchange profile.

When you receive an inbound signed pull request, the certificate is extracted and the user ID is generated from the fields specified. From this information, the response is identified by locating the message that is tagged with that user ID, and pulled. Then, the message is packaged and sent as the pull response.

Digital certificates that are used by AS4 Microservice comply with the X.509 standard, which specifies the information that is required and the format for sending it. Digital certificates contain information about the organization that it is certifying.

The public key for the organization identifies the public key that is bound to the certified subject. Also, it identifies the algorithm that is used to create the private/public key pair.
The subject specifies the Distinguished Name (DN) of the organization. The DN uniquely identifies the owning organization in the certificate and is a part of the certificate.
The Distinguished Name of the CA that issued the certificate
The date on which the certificate is first valid
The expiration date of the certificate
The version number of the X.509 standard that was followed to create the certificate; indicates the format and fields that can be used.
The serial number of the certificate (unique within the CA)
The signature algorithm that specifies the hashing and digital signature algorithms that are used to digitally sign the certificate
The certificate usage specifies the approved use of the certificate, which dictates the intended use of this public key.
Extensions allow other data to be encoded into the certificate to expand the function of the certificate. Additionally, extensions allow organizations to customize the use of certificates within their environments

When you use certificates to identify participants in signing and secure workflows, you can store those certificates on a directory server. Then, participants can search the directory server to expand their list of trusted identities. When you receive a certificate from a partner, their name is added to your list of trusted identities as a contact.

When you receive a certificate from a CA, the certificate is signed by the issuing CA with a digital signature. You verify that signature by using a CA certificate, from which you obtain the public key for the CA. You can use the CA public key to validate other certificates that are issued by that authority. Recipients of your certificate use the CA public key to check the signature. AS4 Microservice trusts public certificates that are received with the configured CA store after it validates the certificate with the specified Certificate Revocation List (CRL).

When you receive the certificate for a partner, you can use a certificate chain to obtain the root CA certificate. The certificate chain, also known as the certification path, is a list of certificates that are used to authenticate an entity. The chain begins with the certificate of your partner. Then, each certificate in the chain is signed by the entity that is identified by the next certificate in the chain. The chain ends with a root CA certificate. The root CA certificate is always signed by the CA. Additionally, all the signatures of all certificates in the chain must be verified until the root CA certificate is reached.