Introducing iCert: Decentralized Digital Certificate Management on Internet Computer
What is iCert?
iCert is a decentralized digital certificate management platform built on the Internet Computer that enables secure, verifiable, and tamper-proof digital certificates. Think of it as a “Let’s Encrypt for digital credentials” but with the added power of blockchain verification and community-driven reputation.
Digital certificates ranges from tls/ssl certificates to more complex usage .
Key Features
For Certificate Issuers:
Create and issue digital certificates with custom metadata
Leverage IC’s chain-key signatures for cryptographic security
Build reputation through community endorsements
For Certificate Holders:
Share certificates instantly via QR codes
Manage your professional portfolio
Track your reputation score across the ecosystem
For Verifiers:
Scan QR codes to instantly verify certificate authenticity
Access transparent endorsement and rating systems
Trust the blockchain-verified credentials
For Developers & Domain Owners:
ACME protocol implementation for SSL/TLS certificates
Chain-key signed X.509 certificates
Automated certificate renewal and management
Technical Innovation
iCert leverages IC’s unique capabilities:
Chain-key signatures for decentralized certificate authority
ECDSA integration for cryptographic verification
HTTP outcalls for external data integration
Internet Identity for secure authentication
X.509 certificate generation with IC based chain key cryptography
Real-World Impact
Problem Solved: Traditional digital certificates suffer from centralization risks, verification complexity, and lack of transparency. iCert addresses these by creating a trustless, verifiable certification ecosystem.
Feature Priorities: Which features would you find most valuable?
User Experience: How can we make certificate verification more intuitive?
Integration Ideas: What platforms should we integrate with?
Security Concerns: What security aspects should we focus on?
Adoption Strategy: How can we encourage widespread adoption?
Current Status
Completed:
Core certificate management system
QR code verification
Endorsement and reputation algorithms
ECDSA and HTTP outcalls integration
Frontend foundation
In Development:
ACME server implementation
Chain-key signature infrastructure
Advanced UI/UX features
Mobile responsiveness
Vision
iCert aims to become the go-to platform for decentralized digital credentials, serving as both a certificate management system and a decentralized Certificate Authority. We believe this showcases IC’s potential for real-world enterprise applications.
Join the Discussion
What aspects of digital certificate management frustrate you most?
How would you use a decentralized certification platform?
What features would make you switch from traditional certificate authorities?
Any security or privacy concerns we should address?
Your feedback will help shape iCert’s development and ensure we’re building something the community truly needs!
Project: iCert - Decentralized Digital Certificate Management
I run an indie game server and need the SSL certificate for proper WebSocket integration. So this feature right here, I’m definitely waiting on since ACME is the current choice for validating my server certificates. If you could make this work natively with ACME-based applications, it would be absolutely groundbreaking for game developers, web server hosters, cloud developers and more.
From my understanding you could be independent but also be signed off by an existing CA for best of both worlds
I feel like getting broad support of clients/software starting out would need traditional CAs but if you grow, independence would be easier
Focus on SSL certificates first. The indie game developer comment shows you might have real demand. If you can make ACME work as a drop-in replacement for Let’s Encrypt, you’ll have actual users immediately. Don’t dilute focus with diplomas and other use cases yet.
Solve the browser trust problem now. Get your root CA signed by traditional authorities first. Nobody will use certificates their browsers don’t recognize. You can build independence later, but you need adoption first.
Make migration dead simple. I should only need to change my ACME server URL. If it requires more changes than that, most developers won’t bother.
Be transparent about costs. “No gas fees” sounds great but how do you sustain this? What happens when IC costs change? Developers need predictable pricing.
Security audit timeline. You’re building a CA. When are you planning third-party audits? This can’t be an afterthought.
Ship the ACME server first. Get that working perfectly before adding features. The SSL use case alone could drive significant adoption if executed well.
I think this guy is right. Very practical things that I need to know as a developer.. it needs to be easy to implement, trusted, and just not worry about. And if it costs me, I don’t just want to pay in ICP, but rather USDC/USDT. I know it’s a lot of upfront work, but that’s why the solution hasn’t been built yet.
Right now, ICP canisters support threshold ECDSA on secp256k1, which works for Bitcoin/Ethereum integrations. But for X.509/TLS certificates, the global PKI ecosystem (browsers, OS trust stores, OpenSSL, etc.) requires secp256r1 (P-256).
Without P-256 support, certificates issued on ICP won’t be browser-compatible, which is a major adoption blocker for decentralized CA use cases like iCert.
Request: Can we get an update or roadmap for threshold ECDSA secp256r1 (P-256) support on ICP? This would unlock not only decentralized SSL/TLS, but also verifiable credentials, IoT device certificates, and broader identity use cases.
On Ed25519, that’s something we had already considered even before the meeting, and also discussed with @cryptoschindler as a possible bridge until secp256r1 is fully integrated. It definitely works for some use cases (credentials, IoT, DAO attestations)….since they’re practical demands for it already , even though it doesn’t unlock browser-trusted SSL/TLS yet.
It’s even more encouraging now with confirmation that Dfinity plans to integrate P-256 into the stack , so we can move forward pragmatically with Ed25519 in the meantime, knowing the full solution is coming.
In the meantime, we’re pushing ahead with ACME + SSL as the first focus, while aligning long-term on P-256 once it’s available.
Key Features
Technical Innovation
Real-World Impact
Community Feedback Needed
Current Status
Completed:
In Development:
Vision
Join the Discussion
Request: Can we get an update or roadmap for threshold ECDSA secp256r1 (P-256) support on ICP? This would unlock not only decentralized SSL/TLS, but also verifiable credentials, IoT device certificates, and broader identity use cases.