For context, each Aggregator client is issued a certificate from the DNSP MICA / ICA.

Step 1: OEM to Create a 2030.5 private key and Generate a CSR

Please ensure that you keep the private key used in this process secure at all times.
Here is a script for this first step:

cert_name=$1

pk_alg="ecparam"
pk_alg_name="prime256v1"

mkdir -p private
mkdir -p csrs

echo "-- Creating Key Pair"
openssl $pk_alg \
    -genkey \
    -name $pk_alg_name \
    -out private/$cert_name.pem

echo "-- Creating CSR"
openssl req \
    -new \
    -key private/$cert_name.pem \
    -subj "/" \
    -out csrs/$cert_name.csr

Step 2: OEM to gather “Standard” and "Non Standard" parameters to accompany the CSR

The following instructions refer to two terms that may need further clarification for the reader: hw_type_serial and hw_type_pen.

• The hw_type_pen is the Private Enterprise Number of the OEM or third party (e.g. Fronius or GE).

• The 2030.5 standard does not specify distinct differences between "device" certificates, where devices can be any of the following: Direct Clients, Aggregator Clients or Servers. The serial number field is an unstructured field that the manufacturer should assign according to its own policies and SHOULD be related to the serial number or other identifier on the device’s external physical label.

  Third parties generating CSR's for signing can treat this field as something unique to their server / aggregator client and is free form.

If you need to review the extensions (especially HardwareModuleName) this python3 script can be used as an example:

import os 
from cryptography import x509 from cryptography.x509.oid import ExtensionOID from pyasn1.codec.der.decoder import decode 
def load_csr(csr_path: str):     with open(csr_path, "rb") as pem_file:          csr = x509.load_pem_x509_csr(pem_file.read())     return csr 
csr_name = "example" csr = load_csr(csr_name + ".csr") 
print("MANUAL CSR VALIDATION - Please validate the below output") print('Extensions:') 
for ext in csr.extensions:     print(ext) print("\n") 
val = (     csr.extensions.get_extension_for_oid(ExtensionOID.SUBJECT_ALTERNATIVE_NAME)     .value.get_values_for_type(x509.OtherName)[0]     .value ) 
print('Decoded "SubjectAlternativeName" value:') received_record, rest_of_substrate = decode(val) print(received_record.prettyPrint()) print('=====================')

It should produce an output similar to:

Decoded "SubjectAlternativeName" value: Sequence:  field-0=1.3.6.1.4.1.61913.10.1.2  field-1=061913240522

Where field-0 and field-1 represent the items shown in later config file examples:

[ HardwareModuleName ] hwType                  = OID:1.3.6.1.4.1.<hw_type_pen>.1.1.1 hwSerialNum             = OCT:<hw_serial>

After gathering the PEN and Serial Number, and due to technology choices (AWS API gateway for example), some aggregators require a second “Non Standard” Server certificate that has a Subject Alternative Name (SAN) dns name populated. If this is the case, you should include this DNS name as an extra item to your request.

So let's recap. Please provide to your DNSP:

• your Private Enterprise Number (PEN);
• a Serial Number of your choice;
• optionally, a Subject Alternative Name (SAN) dns name.

Step 3: OEM to Submit the CSR with extra information to SwitchDin
The OEM submit the aggregator client certificate CSR to the SwitchDin Help Centre Portal using this form containing the following information:

• hw_type_pen
• hw_serial
• Which environment Test / Prod ?
• san dns [optional]
• Certificate Authoriser details
• Certificate Manager details (if different from Authoriser)

Step 4: SwitchDin to Verify the CSR
SwitchDin will verify the CSR running the following command:

openssl req -noout -text -in <>.csr

The output should look like:

Certificate Request:
    Data:
        Version: 1 (0x0)
        Subject: 
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:d7:c6:ec:2d:36:7c:7b:bf:68:ba:23:cf:cb:b4:
                    57:e7:80:7d:4c:5b:b4:2f:46:c5:3d:82:98:a7:0a:
                    be:5d:cd:0d:3c:49:7d:ae:78:0b:fd:17:8c:a0:12:
                    c7:70:c5:f7:68:1f:6b:a4:95:00:45:01:c9:c9:92:
                    81:7a:80:8b:39
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        Attributes:
            (none)
            Requested Extensions:
    Signature Algorithm: ecdsa-with-SHA256
    Signature Value:
        30:45:02:20:68:f6:99:ac:db:cb:51:0b:5e:f9:59:73:41:9e:
        d0:c3:4e:9c:69:63:21:b2:1d:c2:d0:b2:2a:6b:5f:33:ae:01:
        02:21:00:e2:17:dc:07:5a:d9:41:65:e7:ac:00:98:d4:fc:6d:
        84:65:40:0d:d5:6e:f1:8b:8b:ea:e0:6a:44:67:24:47:be

Step 5: SwitchDin check ID of OEM Certificate Authoriser and Certificate manager and request electronic signature of Policy and Practice Statement

This step is done electronically using DocuSign services.

Step 6: SwitchDin securely share OEM certificates with the OEM

SwitchDin sign the CSR against the DNSP MICA and securely return to the OEM three certificates:

• Aggregator Certificate
• Intermediate Certificate
• SERCA Certificate

SwitchDin will also share the following data capture:

• Hardware Module Name Type
• Hardware Module Name PEN
• Hardware Module Name Serial Number
• Certificate Policies
• LFDI
• Certificate Serial Number
• Expiry Date
  
  

Step 7: SwitchDin securely share Aggregator Bundle with the DNSP

The DNSP securely receive from SwitchDin an Aggregator Bundle composed of:

• Aggregator Certificate
• Intermediate Certificate
• SERCA Certificate

SwitchDin will also share the following data capture:

• Hardware Module Name Type
• Hardware Module Name PEN
• Hardware Module Name Serial Number
• Certificate Policies
• LFDI
• Certificate Serial Number
• Expiry Date

Here is a swim lane diagram highlighting the main steps: