Skip to main content

US Hosted Signing Service

he FCC is requiring all voice service providers with a STIR/SHAKEN implementation obligation to use their own STIR/SHAKEN certificate(s) and authenticate (sign and attest) their own calls by June 20, 2025, in accordance with an Order released on November 22, 2024, outlining the role of third parties in implementing STIR/SHAKEN (“Third Party Authentication Order”).

Hosted Signing Service allows Bandwidth to sign calls using your own SHAKEN certificate and signing policy.

Steps Prior to Implementing Hosted Signing Service​

In order to use Bandwidth’s Hosted Signing Service, you will need an active SHAKEN certificate(s) issued to your company. Bandwidth is not able to assist customers with obtaining a SHAKEN certificate, and we encourage customers to engage their legal counsel for advice and assistance specific to their business needs.

Step 1: Complete the pre-requisites​

Before you can register with the STI-PA and get a certificate from an STI-CA, there are a few important steps that you will need to take.

Furthermore, several other requirements must be met prior to leveraging this guide:

  • Obtain an Operating Company Number (OCN or “Company Code”) from the Nation Exchange Carrier Association (NECA).
  • Have a current FCC Form 499-A on file with the FCC.
  • Establish a Valid Registration in the Robocall Mitigation Database (RMD).

Step 2: Register with the policy administrator (STI-PA OR “PA”)​

Begin by registering your organization with the STI Policy Administrator (STI-PA). This involves completing the iconectiv online registration form where you’ll provide essential details about your company and its operations. More details are available from iconectiv in its guides for service providers and resporgs.

Step 3: Select a certificate authority (STI-CA OR "CA")​

After your STI-PA account is activated, the next step is to choose a STIR/SHAKEN Certification Authority (STI-CA) approved by the STI-PA to issue your organization’s STIR/SHAKEN certificates. The CA will use the SPC token from the STI-PA activation step to verify eligibility for your organization to obtain a digital certificate.

Certificate Provisioning​

Bandwidth has implemented an encryption scheme using RSA-OAEP to ensure private keys are not transmitted in plaintext.

The first step is to fetch the encryption key, encrypt your signing private key, and base64 encode for transmission.

Encryption​

Endpoint​

GET /accounts/{accountId}/stirShakenCertificates/encryption-key

Example Request (cURL)​

curl -X GET 'https://api.bandwidth.com/accounts/12345/stirShakenCertificates/encryption-key' \
    -H 'Authorization: Bearer YOUR_ACCESS_TOKEN'

Sample Response​

{
  "key": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtg...\n-----END PUBLIC KEY-----",
  "algorithm": "RSA-4096"
}

Command Line Instructions​

curl -X GET 'https://api.bandwidth.com/accounts/{accountId}/stirShakenCertificates/encryption-key' \
    -H 'Authorization: Bearer YOUR_ACCESS_TOKEN' | jq -r '.key' | sed 's/\\n/\n/g' > bandwidth.pem

openssl pkeyutl -encrypt \
    -pubin -inkey bandwidth.pem \
    -in signing_private_key.pem \
    -pkeyopt rsa_padding_mode:oaep \
    -pkeyopt rsa_oaep_md:sha256 \
    -pkeyopt rsa_mgf1_md:sha256 | base64

This produces a base64 encoded, encrypted payload containing your signing private key. Bandwidth will only accept encrypted payloads.

The signing_private_key.pem is obtained from your STI-CA and is expected to start with

-----BEGIN EC PRIVATE KEY-----

and end with

-----END EC PRIVATE KEY-----.

Upload​

POST /accounts/{accountId}/stirShakenCertificates/
{
    "name": "Signing Certificate",
    "description": "Primary signing certificate for US traffic",
    "certificate": "<Base64 encoded PEM certificate>",
    "encrypted_private_key": "<Base64 encoded encrypted private key>"
}

Certificate Upload Validation Errors​

To ensure the integrity and security of our services, Bandwidth performs validation checks on uploaded certificates.

If a certificate fails any validation, the API responds with a 400 Bad Request status and a description of the specific error.

Common Validation Errors​

  • Certificate Expired: The uploaded certificate must have a future expiration date.

  • Subject Mismatch with Service Provider Code(SPC): The certificate's subject common name should match the configured SPC. For example, if the SPC is Bandwidth=997E, the certificate subject should be CN=SHAKEN 997E,O=Bandwidth.com CLEC LLC,C=US.

  • Missing Expected ASN.1 Identifier: Valid STIR / SHAKEN signing certificates must include the ASN.1 identifier1.3.6.1.5.5.7.1.26.

  • Incorrect Key Algorithm: Certificates should be EC 256 - bit with the SHA - 256 ECDSA signature algorithm.

  • Unsupported Country: Only certificates issued in the United States(C = US) are supported.

  • Private Key Mismatch: The private key must correspond to the uploaded certificate to ensure proper call verification by terminating providers.

Assignment​

Once a certificate is successfully uploaded, it may be provisioned for use in call signing.AcertificateId is returned in the response data which is used to signal your assignment, also known as a profile.

POST /accounts/{accountId}/stirShakenProfiles/
{
    "profileType": "INDIRECT",
    "region": "US",
    "certificateId": "{certificateId}",
    "attestLevel": "B"
}

Confirmation​

Retrieve all profiles to determine if at least one active profile exists for a given region.

Endpoint​

GET /accounts/{accountId}/stirShakenProfiles/

Example Request(cURL)​

curl -X GET \
'https://api.bandwidth.com/accounts/{accountId}/stirShakenProfiles' \
-H 'Authorization: Bearer YOUR_ACCESS_TOKEN'
{
  "links": [
    {
      "href": "/stirShakenProfiles",
      "rel": "self",
      "method": "GET"
    }
  ],
  "data": {
    "totalCount": 1,
    "stirShakenProfiles": [
      {
        "profileType": "INDIRECT",
        "region": "US",
        "certificateId": "{certificateId}}",
        "stirShakenProfileId": "{stirShakenProfileId}",
        "accountId": 12345,
        "active": true,
        "attestLevel": "A"
      }
    ]
  },
  "errors": null
}

Tips for Certificate Management​

tip

Bandwidth recommends you request and provision two certificates, ideally with expiry dates offset from one and other.

This helps ensure continuity of call signing without scrambling to renew at the last minute.

Signing Policy Decisions​

note

When you provision your certificate with Bandwidth to sign calls, it's important to define the level of attestation that reflects your relationship with the call's origin and the telephone number used. This helps establish trust and transparency in the call verification process.

There are three attestation levels to consider:

  • Full Attestation (A)
  • Partial Attestation (B)
  • Gateway Attestation(C)

Descriptions of A, B, and C level attestation can be found in section 5.2.4 of the SHAKEN standards available here (standards may be amended over time).

caution

Always consult with your legal counsel when making signing policy decisions.

Security Details​

Encryption in Transit​

REST requests are made over TLS and sensitive payloads are required to be encrypted, to ensure encryption in transit.

Encryption at Rest​

Private keys are decrypted in order to conduct validation and then they are stored in the Secure Key Store(SKS).

note

Only the Attestation Service (AS) is able to decrypt and this happens only as part of call signing. The key is encrypted in the database.

Need help? Reach out to our team for dev tips
Contact Us
Our Company
About UsBlogContactNewsroomCareersInvestor RelationsLeadership
Quicklinks
SupportService StatusDevelopersResourcesSecurityPartner ProgramCustomersRelease NotesGlossaryTwilio AlternativeRegulations
Legal
GeneralAccessibilityLaw Enforcement GuideBandwidth Privacy NoticeReport a Phone NumberCookie NoticeTerms of Use
Request trialTalk to an expert
Call Us
+1 800 808 5150
Bandwidth.com CLEC, LLC is a wholly owned subsidiary of Bandwidth Inc. ©2025