PKI Repository
Public certificate repository of DDSign (Centric Global Limited), an Electronic Certification Service Provider licensed under the Kenya Information and Communications Act CAP411A.
E-CSP Identification
Published in accordance with Section 33 of the CA/B Forum Baseline Requirements and the Kenya Electronic Certification Regulations 2010, Regulation 14.
- Legal Name
- Centric Global Limited
- Trading Name
- DDSign
- Registration Number
- DSO-LLC-[PLACEHOLDER]
- Jurisdiction of Incorporation
- Dubai Silicon Oasis, Dubai, UAE
- X.500 Distinguished Name (DN)
- CN=DDSign Root CA, O=Centric Global Limited, L=Dubai Silicon Oasis, ST=Dubai, C=AE
- Internet Address
- www.ddsign.ae
- E-CSP Regulatory Basis
- Kenya ICT Act CAP411A & Electronic Certification Regulations 2010
- Primary Contact
- Info@centglob.com
- Telephone
- +254 715 663 018
PKI Hierarchy
DDSign operates a two-tier PKI. The offline Root CA signs only the Signing CA certificate. The Signing CA issues end-entity certificates to subscribers.
Offline Root CA
DDSign Root CA
Online Signing CA
DDSign Signing CA 1
End-Entity (Subscriber)
Subscriber Signing Certificate
Root CA Certificate
Trust anchor for all DDSign-issued certificates. Verify the fingerprint before importing into a trust store.
Subject DN
CN=DDSign Root CA, O=Centric Global Limited, L=Dubai Silicon Oasis, ST=Dubai, C=AE
Issuer
Self-signed
Serial Number
[PLACEHOLDER — populated on issuance]
Validity Period
Not Before: [ISSUANCE DATE]
Not After: [ISSUANCE DATE + 20 years]
Key Algorithm
RSA 4096-bit
Signature Algorithm
sha256WithRSAEncryption
Key Usage (critical)
Certificate Sign, CRL Sign
Basic Constraints (critical)
CA: TRUE, Path Length: 1
Certificate Fingerprints
SHA-256
[PLACEHOLDER: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX]
SHA-1 (legacy reference only — do not use for trust decisions)
[PLACEHOLDER: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX]
Signing CA Certificate
Issued by the Root CA, directly signs subscriber certificates. Relying parties must verify the chain to the Root CA.
Subject DN
CN=DDSign Signing CA 1, O=Centric Global Limited, L=Dubai Silicon Oasis, ST=Dubai, C=AE
Issuer DN
CN=DDSign Root CA, O=Centric Global Limited, C=AE
Serial Number
[PLACEHOLDER — populated on issuance]
Validity Period
Not Before: [ISSUANCE DATE]
Not After: [ISSUANCE DATE + 10 years]
Key Algorithm
RSA 2048-bit
Signature Algorithm
sha256WithRSAEncryption
Key Usage (critical)
Certificate Sign, CRL Sign
Basic Constraints (critical)
CA: TRUE, Path Length: 0
CRL Distribution Points
http://crl.ddsign.ae/signing-ca-1.crl
Certificate Fingerprints
SHA-256
[PLACEHOLDER: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX]
Certificate Policy Summary
Prepared in accordance with ITU-T Recommendation X.509 and IETF RFC 3647. Full CP/CPS available from Info@centglob.com.
CP/CPS Version
1.0
Effective Date
18 Apr 2026
Policy OID (Arc)
1.3.6.1.4.1.[PENDING]
Certificate Classes & Attributes
DDSign issues three classes of certificates with distinct usage, expiration, and key usage extensions.
Class 0 — Root CA Certificate
E-CSP certificate — not issued to subscribers
- Key Usage (critical)
- keyCertSign, cRLSign
- Extended Key Usage
- None
- Validity
- 20 years
- Policy OID
- anyPolicy
- CA Flag
- TRUE, Path: 1
- Reliance Limit
- N/A
Class 1 — Signing CA Certificate
E-CSP certificate — not issued to subscribers
- Key Usage (critical)
- keyCertSign, cRLSign
- Extended Key Usage
- None
- Validity
- 10 years
- Policy OID
- [CP OID].1
- CA Flag
- TRUE, Path: 0
- Reliance Limit
- N/A
Class 2 — Subscriber Signing Certificate
User certificate — issued to individual subscribers
- Key Usage (critical)
- digitalSignature, nonRepudiation
- Extended Key Usage
- emailProtection, documentSigning
- Validity
- 2 years
- Policy OID
- [CP OID].2
- CA Flag
- FALSE
- Reliance Limit
- USD 1,000 / transaction
Class 3 — Timestamp Authority (TSA) Certificate
E-CSP operational certificate — not issued to subscribers
- Key Usage (critical)
- digitalSignature
- Extended Key Usage (critical)
- id-kp-timeStamping
- Validity
- 10 years
- Policy OID
- [CP OID].3
- CA Flag
- FALSE
- TSA Accuracy
- ± 1 second (RFC 3161)
Subscriber Private Key Protection
How DDSign protects Subscriber private keys throughout the certificate lifecycle.
Key Generation
Subscriber private keys are generated on the Subscriber's own device during certificate enrollment. DDSign uses the Web Crypto API or a locally installed cryptographic module to produce the key pair. The private key is created in the browser or on a hardware token and is never transmitted to DDSign servers. Only the public key and the certificate signing request (CSR) leave the device.
Hardware Token Storage
Subscribers who use a FIPS 140-2 Level 2 (or higher) hardware security module or USB cryptographic token generate and store their private key entirely within the hardware device. The key is marked as non-exportable at creation time. Signing operations happen on the token itself, so the raw key material never enters system memory or touches the disk.
Software-Based Key Storage
For Subscribers who store keys in software, the private key is encrypted at rest with AES-256 and locked behind a passphrase that only the Subscriber knows. DDSign does not hold, escrow, or back up this passphrase. If the Subscriber loses it, DDSign cannot recover the private key. The associated certificate must be revoked and a new one issued through the standard enrollment process.
Signing Operations
During document signing, the private key is loaded into process memory only for the duration of the cryptographic operation and is zeroed immediately after use. The signing computation runs locally on the Subscriber's device. DDSign receives only the resulting digital signature and the signed document hash, never the key itself.
No key escrow or backup: DDSign does not copy, archive, or escrow Subscriber private keys at any stage. There is no server-side recovery mechanism. This design means that if a Subscriber loses access to their key material, DDSign cannot recreate or retrieve it.
Subscriber Responsibilities
- ›Store private keys on hardware tokens or HSMs where possible.
- ›Use strong, unique passphrases for software-based key stores. Do not reuse passwords from other accounts.
- ›Do not copy, email, or transfer private key files between devices.
- ›Keep the operating system and browser used for signing operations up to date with security patches.
- ›Report suspected key compromise to DDSign within 24 hours at Info@centglob.com or +254 715 663 018.
Key Compromise Response
On receiving a compromise report, DDSign will revoke the affected certificate, publish the serial number to the Certificate Revocation List (CRL) within 1 hour, and update the OCSP responder. The Subscriber will be notified by email once revocation is complete. A new certificate may then be issued through the standard enrollment and identity verification process.
CRL & OCSP
Certificate revocation and status information.
Routine CRL Update
24h
NextUpdate set per RFC 5280 §5.1.2.5
Emergency CRL Update
< 1h
On confirmed key compromise or revocation
CRL Distribution Points (CDP)
OCSP
Endpoint will be published at http://ocsp.ddsign.ae
CRL integrity: All CRLs are digitally signed by the issuing CA and include
thisUpdate and nextUpdate fields per RFC 5280.
Entries include reason codes and revocation date/time. Content is protected from unauthorised modification by the CA signature.
Certificate Verification Guide
Relying parties must perform all checks before accepting a DDSign-signed document as evidence of a valid electronic signature.
-
1
Verify the issuer's signature
Confirm the signer's certificate was issued by DDSign Signing CA 1, and that the Signing CA certificate was issued by DDSign Root CA. Both signatures must be cryptographically valid. The Root CA SHA-256 fingerprint is published in the Root CA section above.
-
2
Check certificate policy parameters
Verify the certificate contains a DDSign Policy OID in the
certificatePoliciesextension. Certificates without a recognised DDSign policy OID should not be trusted. -
3
Confirm usage parameters
The
keyUsageextension (marked critical) must includedigitalSignaturefor signing certificates. All critical extensions must be understood and complied with. -
4
Check the validity period
Verify the signing certificate was within its
notBefore/notAftervalidity window at the time of signing. Use the embedded RFC 3161 timestamp as the reference time. -
5
Check revocation and suspension status
Download the current CRL from the CDP listed in the certificate's
cRLDistributionPointsextension and confirm the certificate serial number does not appear. A suspended certificate (certificateHold) must not be relied upon until reactivated. -
6
Observe the reliance limit
Reliance on any single DDSign signature transaction is limited to USD 1,000 per certificate per transaction unless a higher limit is expressly agreed in writing. See Terms of Service §4 for full liability terms.
Repository Access Policy
This repository is publicly accessible on a read-only basis to all members of the public, subscribers, and relying parties. No authentication is required to view or download certificates and CRLs.
Write access is restricted exclusively to authorised DDSign operations personnel under dual-control procedures. Modifications to the CPS or CP are subject to a formal change management process requiring request and approval before publication.
Any suspected unauthorised modification should be reported immediately to Info@centglob.com or +254 715 663 018.