Start a conversation Sign in
Start a conversation
  1. CloudSense Support
  2. CloudSense Articles
  3. Articles

PPR API Request Signing: Certificate Expiration vs. Key Rotation

Overview

If you are planning a PPR connectivity certificate renewal because you believe API calls will stop after the certificate expires, it is important to understand how PPR request-signing authentication works. For CloudSense PPR integrations that use request signing, authentication does not rely on X.509 certificate expiration/validity checks; it relies on verifying that each request is signed by a private key that matches the public key CloudSense has on file.

As a result, “certificate expiration” by itself does not block PPR API calls. Calls typically fail only when a key rotation occurs (new private key) without updating the corresponding public key stored by CloudSense.

Key Information

  • Reported concern (verbatim): “once the certificate is expired we won't be able to make any api calls to PPR”.
  • Preventive planning: No specific runtime/API error message was provided; this is guidance for renewal planning rather than an active outage.
  • Authentication behavior: PPR API authentication for request signing does not check X.509 certificate expiration dates or validity periods.
  • What is validated: Each API request must be signed with your private key, and the signature must match the public key CloudSense has stored for your integration.
  • Implication: If a certificate “expires” but you keep signing with the same private key (and CloudSense still has the matching public key), requests continue to authenticate.
  • When failures occur: Authentication failures are expected if your client signs requests with a private key that does not match the public key on file (for example, after a keypair change without a coordinated public-key update).
  • Public key requirements for updates: CloudSense requires a customer RSA public key, 2048-bit, in PEM format.

Customer Impact

No action is required solely due to a certificate expiration date, as certificate validity periods are not used in PPR request-signing verification.

If you are rotating/changing the signing keypair, you must coordinate a public-key update with CloudSense to avoid authentication failures. Use the following recommended approach:

  1. Extract or generate the RSA 2048-bit public key in PEM format.

    If you have a certificate file and need to extract the public key, this OpenSSL example produces a PEM public key file:

    openssl x509 -in path_to_certificate/certificate_name.crt -noout -pubkey -out destination_folder_path/new_certificate_name.pem
  2. Submit a provisioning request to update the stored public key.
    • Attach the generated .pem public key file to your provisioning request.
    • Coordinate the date/time of the public-key update using your designated provisioning/security contact channel: <provisioning_contact>.
  3. Perform a coordinated cutover.
    • At the agreed cutover time, CloudSense updates the stored public key.
    • You switch your client/integration to sign requests using the matching new private key.
  4. Validate immediately after the change.
    • Run a representative signed PPR API call end-to-end.
    • Confirm the call succeeds (HTTP success and expected payload/behavior).
    • If authentication fails, confirm the correct environment (ITT/UAT/Production), the correct public key is on file for that environment, and the client is using the matching private key.

Expected outcome: After CloudSense updates the stored public key and your client signs with the corresponding private key, signed API requests should succeed. If the private/public keypair does not match, authentication will fail (expected behavior).

Frequently Asked Questions

1. How do I know if I’m dealing with “certificate expiry” vs. a key mismatch?
If requests fail only after you changed/rotated keys (new private key) or deployed a new cert/keypair without updating the CloudSense-side public key, it’s a key mismatch. Certificate expiration alone is not used in the authentication validation for PPR request signing.
2. Do I need a CA-signed certificate (vs self-signed) for PPR API authentication?
For PPR API request signing, the critical requirement is the 2048-bit RSA public key in PEM format that matches the private key used to sign requests. The certificate’s CA signature and its expiration date are not what the signing authentication checks.
3. What exact format should I send CloudSense?
Send the RSA 2048-bit public key in PEM format (the contents of a public_key.pem-style file). If starting from a .crt, you can extract the public key with: 
openssl x509 -in path_to_certificate/certificate_name.crt -noout -pubkey -out destination_folder_path/new_certificate_name.pem
4. What should I verify right after the public key is updated?
Verify that your integration is signing requests using the private key that pairs with the newly provided public key, then run a real PPR API call end-to-end and confirm it succeeds.
5. What if API calls still fail after the update?
Re-check (1) the environment targeted (ITT/UAT/Production), (2) that the correct public key was uploaded for that environment, and (3) that the client is using the matching private key. If it still fails, provide the failing request timestamp, environment, and the exact error response from the API gateway/service for further investigation.
Choose files or drag and drop files
ai_initiated
atlas_studio
kb_automation
Was this article helpful?
Yes
No

  1. Matej Storga

  2. Posted
  3. Updated

Comments