Scenario: Create a Digital Twin Instance that uses a mTLS Certificate

If you receive data from a device, then you must use authentication with your digital twin instance. This scenario explains how to use a certificate to authenticate a digital twin instance for a device.

Mutual TLS (mTLS) is a security protocol that ensures both the client and server authenticate each other's identity during communication. Unlike standard TLS, which authenticates only the server, mTLS adds a layer of trust by requiring both client and server to present valid certificates. Alternatively, if you are setting up a test environment you can use a secret to authenticate the digital twin instance.
  1. Create a Key
  2. Create a Certificate Authority
  3. Generate a new private key
  4. Create a certificate that's managed externally
  5. Create a digital twin instance that uses a certificate
  6. Get a digital twin's instance details
  7. Subscribe to a topic using MQTTx
  8. View device data in APEX
  9. Rotating Certificates for a Digital Twin Instance

Best practices

Before you Begin

Make sure you have the required permissions. An administrator grants access by creating the required policies. For more information, see Prerequisites for the policies required for certificates and Policy Details for the Internet of Things (IoT) Platform for policies required for IoT resources.

Certificate policies

When you create a digital twin instance if you use a certificate for authentication, then you need the following policy so that the IoT domain can read the certificate.

Let any IoT user read certificates in a specific compartment for an IoT domain:
Allow any-user to {CERTIFICATE_BUNDLE_READ, CERTIFICATE_READ} in compartment <compartment-name> where request.principal.type = 'iotdomain'
Allow any-user to {CERTIFICATE_AUTHORITY_BUNDLE_READ, CERTIFICATE_AUTHORITY_READ} in compartment <compartment-name> where request.principal.type = 'iotdomain'
Allow any-user to {CABUNDLE_READ} in compartment <compartment-name> where request.principal.type = 'iotdomain'

Step 1: Create a Key

You must have an existing hardware-protected, symmetric encryption key in Oracle Cloud Infrastructure (OCI). To check if you have a Master encryption key or to create a new one:

  1. Go to Identity & Security, and then select Vault.
  2. Select the Compartment you want to use for your IoT resources.
  3. To create a key, select Create Key and follow the instructions in Creating a Master Encryption Key.
  4. Or from the list of Vaults, select the Actions menu next to the Vault you want to use, and then select View Vault Details.
  5. Select Master encryption keys to view Keys. Select View Key Details to find the Protection Mode and confirm it's HSM (Hardware Security Module).

Step 2: Create a Certificate Authority

Use the Certificates service to create a root certificate authority (CA) or a subordinate CA. For more information, see Creating a Certificate Authority.

This example task explains how to issue a certificate with a private key that you manage externally using a subordinate CA.

You must already have a root CA to create a subordinate CA.

  1. Log in as an Administrator, with the correct policies to perform these actions. You must have the appropriate level of security access to create a CA.
  2. On the Certificate Authorities list page, select Create Certificate Authority. If you need help finding the list page, see Listing Certificate Authorities.
  3. Select Compartment, and then select the compartment where you want to create the CA.
  4. Under Certificate Authority Type, select the type Subordinate Certificate Authority: any CA that's not the root CA in a hierarchy containing other CAs.
  5. (Optional) Enter a unique display name for the CA. This name helps you identify the CA for administrative purposes but doesn't appear as part of the CA certificate. Avoid entering confidential information.
    Note

    No two CAs in a tenancy can share the same name, including CAs pending deletion.
  6. (Optional) To apply tags, select Show Tagging Options. For more information about tags, see Resource Tags.
  7. Select Next.
  8. Enter subject information. Subject information includes at least a common name (CN) to identify the owner of the CA certificate. Depending on the certificate's intended use, the subject might identify a person, organization, computer endpoint, or a device. The format of the subject information must conform to RFC 5280 standards. You can use wildcards to issue a certificate for multiple domain or subdomain names.
  9. Select Next.
  10. Under Authority Configuration, confirm or select the vault that contains the encryption key that you want to use for the CA certificate. Optionally, select Change Compartment to specify a different compartment. For information about creating and managing vaults, see Managing Vaults.
  11. Under Key, select the key in the vault that you want to use. The list includes only the asymmetric keys in the vault because Certificates only supports asymmetric keys. You can select from Rivest-Shamir-Adleman (RSA) keys that are 2,048 bits or 4,096 bits. You can also select elliptic curve cryptography digital signature algorithm (ECDSA) keys that have an elliptic curve ID of NIST_P384. Specifically, the list includes only these types of asymmetric keys that are protected by a hardware security module (HSM). Certificates don't support the use of software-protected keys. For more information about creating and managing keys, see Managing Keys.
  12. Under Signing Algorithm, depending on the key algorithm family select one of the following options:
    • SHA256_WITH_RSA: RSA key with a SHA-256 hash function
    • SHA384_WITH_RSA: RSA key with a SHA-384 hash function
    • SHA512_WITH_RSA: RSA key with a SHA-512 hash function
    • SHA256_WITH_ECDSA: ECDSA key with a SHA-256 hash function
    • SHA384_WITH_ECDSA: ECDSA key with a SHA-384 hash function
    • SHA512_WITH_ECDSA: ECDSA key with a SHA-512 hash function
  13. Select Next.
  14. Configure the expiry rule. Under Maximum Validity Duration for Certificates (Days), specify the maximum number of days that a certificate issued by this CA can be valid. We strongly recommend a validity period of no more than 90 days.
  15. On the Revocation Configuration page, if you don't want to configure a certificate revocation list (CRL), select the Skip Revocation checkbox.
  16. Select Next.
  17. Confirm that the information is correct, and then select Create Certificate Authority. It can take a few minutes to create certificate-related resources.
  18. If the Certificate Authority was successfully created, then the summary details is displayed.

Step 3: Generate a New Private Key

Create a private key and a certificate signing request (CSR) using OpenSSL.

Note

For security, consider performing this step on the device to keep the key private and never share the key externally.
  1. Use this command to generate a new private key private.pem and a certificate signing request csr.pem with RSA 2048-bit encryption. This example shows using the -nodes parameter that specifies without password protection and uses the v3_req extensions.
    openssl req -nodes -newkey rsa:2048 -keyout private.pem -out csr.pem -extensions v3_req
    Note

    If you are using Linux, by default the OpenSSL.cnf file comments out the extension, for example, if you see something like this in the OpenSSL config file: /etc/pki/tls/openssl.cnf
     # req_extensions = v3_req # The extensions to add to a certificate request
    Then remove the # to uncomment out the extensions, so the file looks something like this:
    req_extensions = v3_req  # The extensions to add to a certificate request
    To verify OpenSSL is using extensions v3_req you can verify the output contains:
    X509v3 extensions:
        X509v3 Basic Constraints: critical
            CA:FALSE
  2. This example shows the certificate request input fields and example values. Enter information that will be incorporated into your certificate report, as a Distinguished Name (DN).

    Enter the common name. You can find the common name on the Subject Information tab of the Certificate details page, see step 8 Create a Certificate Authority or for help finding the certificate details page, see Listing Certificates:
    Country Name (2 letter code) []: US
    State or Province Name (full name) [Some-State]:
    Locality Name (eg, city) []:
    Organization Name (eg, company) []:
    Organizational Unit Name (eg, section) []:
    Common Name (Enter common name from the certificate details.) []:common-name
    Email Address [your@email.com]:
    
    Please enter the following 'extra' attributes
    to be sent with your certificate request
    A challenge password []:
    An optional company name []:

Step 4: Create a Certificate that's Managed Externally

You can generate a certificate signing request (CSR) and private key on the server where you plan to install the certificate, and then submit that CSR to a CA to issue a certificate, while managing the private key externally.

This task describes how to issue a certificate with a private key that you manage externally. For more information on other ways to use a certificate, see Creating a Certificate to Manage Externally and Managing Certificates.
  1. In the Console, open the navigation menu, select Identity & Security.
  2. On the Certificates list page, the list of Certificate Authority for a specific compartment is displayed.
  3. Find the Certificate you want to work with, select the Actions menu at the end of the row.
  4. Select Issue Certificate.
  5. Under Certificate Type, to issue a certificate from a Certificates service CA that's managed by an external, third-party CA, select Issued by internal CA, managed externally.
  6. Enter a unique display name for the certificate. Avoid entering confidential information.
    Note

    No two certificates in the tenancy can share the same name, including certificates pending deletion.
  7. (Optional) Enter a description to help identify the certificate. Avoid entering confidential information.
  8. For certificates that a third-party CA manages, you don't need to provide subject information. Instead, select Next.
  9. Under Certificate Signing Request, provide certificate contents by selecting Upload File, and then select Select One to upload the certificate as a file in PEM format.
  10. Or select Paste Content, and then select the text box to paste the certificate contents directly.
  11. Select Next.
  12. You can't configure automatic renewal for certificates that the Certificates service doesn't manage. Select Next to continue.
  13. Verify the summary information is correct, and then select Create Certificate.
  14. View the Certificate details page opens. Under the Versions, find the name of the certificate you want to view, go to the Actions menu at the end of the row, select View Content. For more information, see Viewing Certificate Details.
  15. Select Download and Save the Certificate PEM file.
  16. On the Certificate details page, go to the Subject information tab, copy the Common Name for the certificate to use in the next step.

Step 5: Create a Digital Twin Instance that uses a Certificate

To authenticate a device to send data you can create a digital twin instance using the --auth-id parameter and the <certificate-OCID> created in the previous step.

Use this command and parameters to create a digital twin instance. Replace the <common-name-for-the-certificate>. Replace the <certificate-OCID> with the Certificate OCID for your environment. Find these values on the Certificate details. For more information, see Viewing Certificate Details:

oci iot digital-twin-instance create --iot-domain-id <iot-domain-OCID> --auth-id <certificate-OCID> --external-key <common-name-from-certificate-details>

For a complete list of CLI parameters, see oci iot digital-twin-instance create and see Creating a Digital Twin Instance for more information.

Optional Step 6: Get a Digital Twin's Instance Details

Use this command to view the details for a digital twin instance. The response contains the digital twin's instance OCID, authentication id, and the external key.
oci iot digital-twin-instance get --digital-twin-instance-id <digital-twin-instance-OCID>
For more information, see Getting a Digital Twin's Instance Details.

Step 7: Send Data

Depending on your scenario, you can connect to the digital twin instance using MQTTS, HTTPS, or using WebSocket. For more example scenarios, see Connecting a Device.

  • Using Curl

    POSIX-style shells: Use this curl command when using bash, zsh, macOS Terminal, Linux, or Git Bash on Windows to send sample plain text message test the connection. Replace the device-cert.pem and the device-key.pem with the path to the files for your environment.
    curl --cert /path/device-cert.pem --key /path/device-key.pem \
    -H "Content-Type: text/plain" \
    -d "sample data 1" \
    "https://<iot-domain-short-id>.device.iot.<region>.oci.oraclecloud.com/sampletopic"

    Windows Powershell: Use this curl command, replace the device-cert.pem and the device-key.pem with the values for your environment.

    curl.exe --cert /path/device-cert.pem --key /path/device-key.pem \
    -H "Content-Type: text/plain" \
    -d "sample data 1" \
    "https://<iot-domain-short-id>.device.iot.<region>.oci.oraclecloud.com/sampletopic"

    Use the external key stored in Step 5: Create a Digital Twin Instance that uses a Certificate. Shell quotation marks are not part of the external key unless they were deliberately stored as part of its value. For authentication checks, see Troubleshooting Certificate Rotation.

  • Use any MQTT client to subscribe to a topic using MQTTS. This example uses MQTTx.

    To send sample data and test the connection:

    1. Enter the device host as the host, for example:
      mqtts://<domain-short-id>.device.iot.<region>.oci.oraclecloud.com
    2. Enter the port: 8883
    3. Client ID: your-client-id
    4. Clean Start: True
    5. Turn on the toggle to enable TLS.
    6. Select the option: CA or Self signed certificates
    7. Enter the client certificate file location, from step 15 in Create a Certificate that's Managed Externally: your-certificate.pem
    8. Enter the client key file location, from step 1 in Generate a New Private Key: your-private-key.pem
    9. Select Connect.

      MQTTx

      Connect using MQTTx.

    10. Select New Subscription to receive data from a device.
    11. Enter the endpoint as the Topic.
    12. This example shows messages published to the /endpoints/4321 topic, at Quality of Service (QoS) level 1. topic:
      {
        "pulse": 300,
        "s02": 400
      }
      {
        "test": 100
      }

      Subscribe to a topic in MQTTx.

Optional Step 8: Monitor the IoT Data in APEX

If you configured access to view your data in APEX and the device sent raw data, then you can use this SQL statement to view digital twin instance raw data response in APEX.
select * from <domain-short-id-from-device-host>__IOT.RAW_DATA
where digital_twin_instance_id = '<digital-twin-instance-ocid>'

Rotating Certificates for a Digital Twin Instance

When a digital twin instance uses a subordinate certificate authority (CA) for authentication, rotate versions under the same CA resource OCID to keep the instance's authentication ID (authId) unchanged. During the supported rotation overlap, IoT can authenticate device certificates issued by both the current and previous subordinate-CA versions.

A root CA cannot be used as the digital twin instance's authentication ID.

Coordinate certificate changes with the devices that use them, and verify authentication and data ingestion with the replacement credentials before retiring previous credentials.

Choose the procedure that matches the authentication ID: Rotating a Subordinate CA Used for Device Authentication or Rotating an Imported Certificate Used for Device Authentication. Updating an individual certificate replaces the device credential; updating a subordinate CA changes the issuer trusted for device certificates.

Rotating a Subordinate CA Used for Device Authentication

Update a subordinate CA and migrate devices to replacement certificates without changing their digital twin instances' authentication IDs.

This procedure applies when the digital twin instance's authentication ID (authId) references a subordinate CA in the Certificates service. It doesn't cover authentication IDs that reference an individual certificate or a CA bundle. A root CA cannot be used as the authentication ID.

Make sure you have permission to manage the CA and its certificates, and that the IoT domain retains permission to read them. See Prerequisites and the certificate policies in this topic.

Plan the device handover before changing the CA. Identify all devices that depend on the previous credentials, arrange secure distribution of replacement credentials, and keep the credentials needed by devices that haven't migrated. Certificate validity and revocation still apply during the supported rotation overlap.

  1. Confirm the subordinate-CA OCID used by each affected digital twin instance.

    Use Getting a Digital Twin Instance to check the authentication ID. Keep this ID unchanged throughout the procedure. Renew versions under the same subordinate-CA resource, rather than creating a different CA and substituting its OCID.

  2. Prepare the replacement CA version using the Certificates service renewal procedure.

    See Renewing a Certificate Authority, including its guidance on rotating the CA's Vault key when new key material is required. Review the effect on other resources that use the key before changing it. Set the replacement version's validity period to cover the planned handover.

  3. Make the replacement subordinate-CA version current when you are ready to begin the handover.

    If you staged the version as pending, use Making a Certificate Authority Version Current. Confirm that the intended version is CURRENT and the preceding version is PREVIOUS. Don't assume that a pending version can authenticate devices.

  4. Issue replacement device certificates using the current subordinate-CA version and securely provision them to the devices.

    For the externally managed private-key example in this topic, follow Generate a New Private Key and Create a Certificate that's Managed Externally. Preserve each device's certificate identity and its mapping to the intended digital twin instance. Verify the replacement certificate's issuer and validity. Protect private keys and don't include them in logs or shared examples.

  5. Switch a controlled set of devices to the replacement credentials and verify each device using a fresh connection.

    Use the applicable Send Data example to authenticate and send a test message. Confirm that data reaches the intended digital twin instance. An existing connection isn't evidence that the replacement credentials can authenticate. If verification fails, investigate before switching more devices.

  6. Migrate the remaining devices and verify authentication and ingestion before retiring the previous credentials.

    Track devices that still use the previous certificates. Complete the migration within the supported overlap and before certificate expiry. Don't revoke or remove a certificate or issuer while a device still depends on it. Do not start another rotation of the same CA until this handover is complete.

  7. Retire the previous device credentials after all affected devices have been verified with the replacement credentials.

    Remove obsolete credentials from devices and provisioning systems according to your organization's credential-retirement policy. Before revoking or deleting a previous CA version, confirm that no other certificate or resource depends on it. Handling compromised credentials requires a separate emergency response; rotation overlap isn't a reason to continue trusting a revoked credential.

The devices use replacement certificates, and the digital twin instances retain the same subordinate-CA authentication OCID.

Rotating an Imported Certificate Used for Device Authentication

Replace a device certificate and its matching private key under the same certificate OCID.

This procedure applies when the digital twin instance's authentication ID (authId) references an individual imported certificate in the Certificates service. For an authentication ID that references a subordinate CA, use Rotating a Subordinate CA Used for Device Authentication. CA bundles aren't covered by either procedure.

Make sure you can update the certificate and that the IoT domain can read it. Plan secure distribution of the replacement credentials before changing the active version.

  1. Check the digital twin instance's authentication ID and external key.

    Use Getting a Digital Twin Instance to confirm the existing certificate OCID. Keep this authentication ID unchanged throughout the handover.

  2. Obtain the replacement device certificate, its matching private key, and the required issuer chain.

    Keep the certificate's common name unchanged and matched to the instance's external key. Verify the replacement certificate's issuer and validity period. Protect the private key during storage and distribution.

  3. Update the existing imported certificate resource with the replacement PEM files.

    Follow Updating a Certificate PEM. Update the same resource rather than importing a separate certificate with a different OCID. Provide the replacement certificate, its matching private key, and the required chain.

  4. Confirm that the replacement certificate version is current before activating it on devices.

    If the replacement isn't current, follow Making a Certificate Version Current. Confirm that the intended version is CURRENT and the preceding version is PREVIOUS. Staging a version doesn't establish that it can authenticate.

  5. Provision the replacement certificate and matching private key, then verify a fresh device connection and data ingestion.

    Disconnect the test client's existing session and configure both replacement files. Keep TLS server-certificate verification enabled. Use the applicable Send Data example, and confirm that the test message reaches the intended digital twin instance. A connected client alone isn't proof of successful ingestion.

  6. Complete the handover before retiring the previous credentials.

    Verify every affected device with the replacement credentials within the supported overlap and certificate validity periods. Keep track of devices that still depend on the previous version. Follow your organization's retirement policy after migration; check dependencies before revoking or deleting a certificate version. Don't begin another rotation of the same certificate until the handover is complete.

The device uses the replacement certificate and private key, and the digital twin instance retains the same certificate authentication OCID.

Certificate Rotation FAQ

OCI Certificates assigns rotation states such as CURRENT, PREVIOUS, and PENDING to certificate versions. For background on these states and version promotion, see Certificate Versions and Rotation States. IoT authentication also depends on the overlap and validity requirements described here.

Does the subordinate-CA procedure change the authentication ID?
No. The procedure rotates versions of the same subordinate CA and retains its resource OCID in authId. Replacing that resource with a different CA OCID is not the same operation. See Rotating a Subordinate CA Used for Device Authentication.
Can I use a root CA as the authentication ID?
No. A root CA can be part of the issuer hierarchy, but cannot be the digital twin instance's authId. Do not substitute a root CA OCID for the subordinate CA or certificate used for device authentication.
Does renewing the CA update the credentials on my devices?
No. Provision the replacement device certificate and its matching private key securely, then verify a fresh connection and successful ingestion. A CA version change alone does not distribute device credentials.
Which procedure applies when the authentication ID is a certificate OCID?
For an individual imported certificate, see Rotating an Imported Certificate Used for Device Authentication. That procedure updates the certificate and its matching private key under the same certificate OCID. The subordinate-CA procedure instead updates the issuer used to authenticate device certificates. Neither procedure covers a CA bundle.
When can I retire the previous credentials?
Verify all affected devices with their replacement credentials before retirement, within the supported overlap and certificate validity periods. Check dependencies before revoking or deleting an issuer. Overlap does not make expired or revoked credentials valid, and an existing connection is not proof that replacement credentials work.

For shared questions, see Credential Rotation FAQ.

Troubleshooting Certificate Rotation

A device fails certificate authentication after a credential or issuer-version change.

The authentication ID, active issuer version, device identity, certificate chain, or client credentials might not match.

  1. Check whether authId references a subordinate CA or an individual certificate. Follow the procedure for that resource type. A root CA is not a valid authentication ID.
  2. For the subordinate-CA procedure, verify that the replacement CA version is CURRENT and that the replacement device certificate was issued by the intended version. Confirm certificate validity, revocation status, and the required issuer chain.
  3. Verify that the client loads the replacement certificate and its matching private key, not stale files. Check the certificate common name against the instance's external key and confirm the intended domain endpoint. See Create a Digital Twin Instance that uses a Certificate.
  4. Test a fresh connection and send data using Send Data. Keep TLS verification enabled. Do not treat an existing session or repeated automatic reconnects as proof of a successful credential handover.
  5. If only the previous credential fails, check its validity, revocation status, issuer version, and supported overlap. Do not delete more credentials or rotate again to investigate.

For persistent failures, use the evidence checklist in Troubleshooting Device Credential Rotation. Never include private keys in diagnostic output.