What You'll Learn

Option A - Without Registry CA

  1. Create A Private Key With OpenSSl
    #openssl genrsa  -out private_key_filename bits
    openssl genrsa  -out private.key 2048
    
  2. Create A Public Key With OpenSSl
    #openssl rsa -in private_key_filename -outform PEM -pubout -out publickey_filename 
    openssl rsa -in private.key -outform PEM -pubout -out public.pem   
    
  3. The Private Key will be saved as private.key and the public key as public.pem

Option B - With Registry CA

  1. Create A Root CA And its Certificate
    #openssl req -x509 -nodes -sha256 -days validity_certificate -newkey rsa:bits -keyout root_key_file -out root_certificate_file
    openssl req -x509 -nodes -sha256 -days 1825 -newkey rsa:2048 -keyout rootCA.key -out rootCA.crt
    
  2. Create A Private Key With OpenSSl
    #openssl genrsa  -out private_key_filename bits
    openssl genrsa  -out private.key 2048
    
  3. Create A Signing Request
    #openssl req -key private_key_filename -new -out csr_filename
    openssl req -key private.key -new -out domain.csr
    
  4. Sign the Csr With Root CA
    #openssl x509 -req -CA root_ca_cert_file -CAkey root_ca_key_file -in csr_filename -out device_cert_filename -days validitiy -CAcreateserial
    openssl x509 -req -CA rootCA.crt -CAkey rootCA.key -in domain.csr -out device.crt -days 365 -CAcreateserial
    

Option A - Without Registry CA

  1. Create A Private Key With OpenSSl
    #openssl ecparam  -genkey -name prime256v1 -noout -out file_name
    openssl ecparam -genkey -name prime256v1 -noout -out ec_private.key
    
    
  2. Create A Public Key With OpenSSl
    #openssl ec -in private_key_filename -outform PEM -pubout -out publickey_filename 
    openssl ec -in ec_private.key -pubout -outform PEM -pubout -out ec_public.pem
    
  3. The Private Key will be saved as ec_private.key and the public key as ec_public.pem

Option B - With Registry CA

  1. Create A Root CA And its Certificate
    #openssl req -x509 -nodes -sha256 -days validity_certificate -newkey rsa:bits -keyout root_key_file -out root_certificate_file
    openssl req -x509 -nodes -sha256 -days 1825 -newkey rsa:2048 -keyout rootCA.key -out rootCA.crt
    
  2. Create A Private Key With OpenSSl
    #openssl ecparam  -genkey -name prime256v1 -noout -out file_name
    openssl ecparam -genkey -name prime256v1 -noout -out ec_private.key
    
  3. Create A Signing Request
    #openssl req -key private_key_filename -new -out csr_filename
    openssl req -key ec_private.key -new -out domain.csr
    
  4. Sign the Csr With Root CA
    #openssl x509 -req -CA root_ca_cert_file -CAkey root_ca_key_file -in csr_filename -out device_cert_filename -days validitiy -CAcreateserial
    openssl x509 -req -CA rootCA.crt -CAkey rootCA.key -in domain.csr -out device.crt -days 365 -CAcreateserial
    
  1. Go To Registry Tab and click on New Registry
  2. If Root CA is needed, Paste the rootCA.crt generated in the previous step and paste it in the authentication.
  3. Enter Registry Details and Click Create. Sample Data is shown below.
    Create-Registry
  4. Enable Custom Onboard in Zero Touch Provisioning Field.
    Custom-Onboard
  5. Choose the Pubsub Topic to forward devices details onboarding via custom onboarding for further process.
  1. In addition to the regular mqtt fields , custom onboard requires a certificate in the username field which is validated against the registry Ca.
    Custom-Onboard
  2. Once Device is connected, a message is forward to the custom onboard pubsub topic.
  1. Device can send messages to the custom onboard forwarding pubsub topic by publishing device messages to /Registry_Id/Device_Id/onboardStatus.
  1. Fetch the details of the custom onboarded device from custom onboard forwarding pubsub topic.
    Custom-Onboard
  2. We can process these details and approve or refuse to custom onboard this device by calling the updateCustomOnboard Method in the Omnicore Sdk or Rest Api. (Update Custom Onboard)
  3. The device should subscribe to mqtt topic /Registry_Id/Device_Id/onboard with Qos 1.If approved , the api requires the details of the device to be onboarded similar to a createDevice call and a message which needs to be sent to be device, once its done the custom onboarded device should receive a message on the mqtt onboard topic with the details sent via api and disconnected from broker.The Client is expected to reconnect once approval is done normally,without any certificate in username field.
  4. If the authorizer needs to refuse this onboard request ,it can call the api with approval as false with custom data if necessary and this is sent to device and then disconnected directly from the broker.