Certificate Lifecycle Management

Overview

Certificates are the foundation of secure WiFi authentication with EAP-TLS and encrypted RADIUS transport with RadSec. Proper certificate lifecycle management ensures continuous, secure network access without disruptions from expired or misconfigured certificates.

This guide covers the complete certificate lifecycle in IronWiFi: issuance, deployment, monitoring, renewal, rotation, and revocation. It complements the Certificate Revocation Guide which focuses specifically on revocation procedures.

Certificate Types in IronWiFi

Understanding the Certificate Hierarchy

Certificate Roles

Certificate	Purpose	Typical Validity	Deployed To
Root CA	Trust anchor for the entire chain	10--20 years	Client devices (trust store)
Intermediate CA	Signs end-entity certificates	5--10 years	IronWiFi platform
RADIUS Server Certificate	Authenticates the RADIUS server to clients	1--2 years	IronWiFi RADIUS servers
Client Certificate	Authenticates users/devices to the network	1--2 years	End-user devices
RadSec Client Certificate	Authenticates your AP/proxy to IronWiFi RadSec	1--3 years	Access points or RADIUS proxy
RadSec Server Certificate	Authenticates IronWiFi RadSec to your equipment	1--2 years	IronWiFi RadSec servers

Certificate Issuance

Issuing Client Certificates for EAP-TLS

Client certificates enable passwordless, phishing-resistant WiFi authentication. IronWiFi supports multiple issuance methods.

Manual Issuance via Console

1. Navigate to Users > select a user
2. Click Certificates > Issue Certificate
3. Configure the certificate:

Field	Description
Common Name	Typically the username or email
Validity Period	Certificate lifetime (1 year recommended)
Key Size	2048-bit or 4096-bit RSA, or ECDSA P-256
Extended Key Usage	Client Authentication

4. Click Generate
5. Download the certificate bundle (PKCS#12 format) and deliver it to the user

tip

Use ECDSA P-256 certificates for mobile devices. They provide equivalent security to 3072-bit RSA with smaller key sizes, resulting in faster TLS handshakes and better battery life.

SCEP-Based Issuance

For automated certificate issuance via MDM:

1. Navigate to Networks > select network > Certificates tab
2. Enable SCEP Server
3. Record the SCEP URL and challenge password
4. Configure your MDM (Intune, Jamf, Workspace ONE) with the SCEP settings:

5. Create an MDM WiFi profile that uses the SCEP certificate for EAP-TLS
6. Deploy the MDM profile to target devices

See the Passpoint Onboarding guide for MDM-specific configuration.

API-Based Issuance

For custom enrollment workflows:

Issuing RadSec Certificates

RadSec certificates authenticate the RadSec transport between your equipment and IronWiFi:

1. Navigate to Networks > select network > RadSec tab
2. Click Generate RadSec Certificate
3. Download the certificate bundle:

   • client-cert.pem

     -- Client certificate

   • client-key.pem

     -- Private key

   • ca-chain.pem

     -- CA certificate chain
4. Install these on your access point or RADIUS proxy

See RadSec Configuration for vendor-specific installation instructions.

Certificate Deployment

Deployment Methods

Method	Best For	Scale
Manual	Small deployments, testing	1--50 devices
MDM/SCEP	Managed enterprise devices	50--10,000+ devices
Passpoint OSU	Guest/visitor onboarding	Any scale
API + Custom Portal	Custom enrollment workflows	Any scale
Group Policy (Windows)	Domain-joined Windows PCs	Enterprise

Deploying via MDM

The recommended approach for managed devices:

1. Configure the SCEP profile in your MDM with IronWiFi's SCEP endpoint
2. Create a WiFi profile that references the SCEP certificate for EAP-TLS authentication
3. Assign the profiles to device groups
4. Monitor deployment status in your MDM console

MDM Deployment Checklist:

• SCEP endpoint URL configured correctly
• SCEP challenge matches IronWiFi Console
• WiFi profile references the SCEP certificate
• Root CA is included in the trusted certificate profile
• Intermediate CA is included in the chain
• Target device group is correct
• Test with a single device before mass deployment

Deploying to Unmanaged Devices

For BYOD or guest devices without MDM:

1. Onboarding Portal -- Direct users to an enrollment portal that generates and installs certificates
2. Email Delivery -- Generate certificates and email PKCS#12 bundles with a temporary password
3. QR Code -- Generate a QR code that links to the certificate download page

warning

When distributing certificates via email, use a separate channel (e.g., SMS) for the PKCS#12 password. Never send the certificate and password in the same email.

Certificate Monitoring

Tracking Certificate Expiration

Monitor certificates across your deployment to prevent outages:

1. Navigate to Networks > select network > Certificates tab
2. View the certificate inventory with expiration dates
3. Sort by expiration date to identify certificates expiring soon

Certificate Status Indicators:

Status	Meaning	Action Needed
Valid	Certificate is within its validity period	None
Expiring Soon	Expires within 30 days	Begin renewal process
Expired	Past the validity end date	Immediate renewal required
Revoked	Manually revoked by an administrator	Reissue if the revocation was in error

Setting Up Expiration Alerts

Configure automated alerts for expiring certificates:

1. Navigate to Account > Notifications
2. Enable Certificate Expiration Alerts
3. Configure the alert thresholds:
   • First alert: 60 days before expiration
   • Second alert: 30 days before expiration
   • Urgent alert: 7 days before expiration
4. Set the notification recipients (email addresses)

tip

Set the first alert to 60 days before expiration. This gives you enough time to plan and execute a certificate rotation without emergency procedures.

Monitoring via API

Integrate certificate monitoring into your existing tools:

Certificate Renewal

Renewal Strategies

Strategy	How It Works	Best For
Auto-renewal (SCEP)	MDM automatically requests new cert before expiration	Managed devices
Manual renewal	Admin generates new cert and deploys it	Small deployments
API-driven renewal	Custom automation triggers renewal	Custom workflows
User self-service	User visits renewal portal to get new cert	BYOD

Auto-Renewal with SCEP/MDM

The most reliable renewal method for managed devices:

1. Configure your MDM's SCEP profile with a renewal threshold (e.g., 30 days before expiration)
2. The MDM automatically requests a new certificate from IronWiFi's SCEP endpoint
3. The new certificate is installed on the device
4. The old certificate is removed by the MDM
5. No user action required

Manual Renewal Process

For certificates that require manual renewal:

1. Identify certificates approaching expiration (see monitoring above)
2. Navigate to Users > select the user > Certificates
3. Click Renew next to the expiring certificate
4. A new certificate is generated with the same Common Name and attributes
5. Download the new PKCS#12 bundle
6. Deploy to the user's device
7. The old certificate remains valid until its expiration (or until revoked)

Renewal Without Downtime

To renew certificates without interrupting user connectivity:

1. Issue the new certificate while the old one is still valid (overlap period)
2. Deploy the new certificate to the user's device
3. Test authentication with the new certificate
4. Revoke the old certificate after confirming the new one works

Certificate Rotation

Rotating RADIUS Server Certificates

When the IronWiFi RADIUS server certificate needs rotation:

1. IronWiFi generates a new server certificate
2. The new certificate is deployed alongside the old one
3. Both certificates are accepted during a transition period
4. Client devices verify the server certificate during EAP authentication
5. After the transition period, the old certificate is removed

note

IronWiFi manages RADIUS server certificate rotation automatically. You do not need to take any action unless you have pinned the specific server certificate on your client devices (not recommended -- see Certificate Pinning below).

Rotating RadSec Certificates

When your RadSec client certificate needs rotation:

1. Generate a new RadSec certificate in the IronWiFi Console
2. Install the new certificate on your AP or RADIUS proxy alongside the old one (if your equipment supports multiple certificates)
3. If your equipment only supports one certificate at a time: a. Schedule a maintenance window b. Replace the certificate c. Restart the RadSec service d. Verify the connection re-establishes

Rotating the Root CA

Root CA rotation is rare but may be necessary:

1. Phase 1 -- Trust Distribution (months before rotation):
   • Deploy the new Root CA to all client device trust stores
   • Both old and new Root CAs should be trusted
2. Phase 2 -- Certificate Issuance (switchover):
   • Begin issuing new certificates signed by the new Root CA chain
   • Existing certificates remain valid until they expire
3. Phase 3 -- Old CA Removal (after all old certs expire):
   • Remove the old Root CA from trust stores
   • This phase may take 1--2 years depending on certificate validity periods

warning

Never remove the old Root CA from trust stores until all certificates signed by it have either expired or been replaced. Premature removal will cause immediate authentication failures for all affected devices.

Chain of Trust

Building a Complete Certificate Chain

For EAP-TLS authentication to succeed, the client must be able to verify the entire chain from the server certificate to a trusted Root CA:

Common Chain of Trust Issues:

Issue	Symptom	Fix
Missing intermediate CA	unable to verify certificate	Include intermediate CA in the server certificate chain
Root CA not in trust store	unknown CA	Deploy Root CA to client devices via MDM or manual installation
Wrong intermediate CA	certificate chain validation failed	Verify the intermediate CA matches the one that signed the server cert
Expired intermediate CA	certificate has expired	Contact IronWiFi to obtain a renewed intermediate CA

Verifying the Chain

Certificate Pinning

What Is Certificate Pinning?

Certificate pinning restricts which certificates a client accepts for authentication, beyond normal chain-of-trust validation. Instead of accepting any certificate signed by any trusted CA, the client only accepts specific certificates or public keys.

Pinning Strategies

Strategy	What Is Pinned	Flexibility	Security
Root CA Pinning	Root CA public key	High -- any cert in the chain works	Moderate
Intermediate CA Pinning	Intermediate CA public key	Medium -- certs from that CA work	High
Leaf Certificate Pinning	Server certificate itself	Low -- must update pin on rotation	Very high

Recommendations

warning

Avoid leaf certificate pinning unless you have a robust, automated process for updating pins before certificate rotation. Leaf pinning causes immediate outage if the server certificate is rotated without updating all clients.

Recommended approach:

1. Pin the Root CA for the best balance of security and operational flexibility
2. Deploy the pinned Root CA hash via MDM or device configuration profile
3. When configuring EAP-TLS on client devices, specify the trusted Root CA rather than the server certificate
4. This allows IronWiFi to rotate server and intermediate certificates without client changes

Configuring Pinning in MDM

iOS/macOS (Configuration Profile):

Windows (Group Policy):

Best Practices

Certificate Lifecycle Checklist

Activity	Frequency	Owner
Review expiring certificates	Weekly	Network admin
Test certificate renewal process	Quarterly	Network admin
Audit issued certificates	Quarterly	Security team
Verify Root CA trust deployment	After any OS update	Device management
Test revocation (CRL/OCSP)	Quarterly	Network admin
Document certificate inventory	Ongoing	Network admin
Review pinning configuration	Before any cert rotation	Network admin

Security Recommendations

1. Use short-lived certificates (1 year) for end-entity certificates to limit exposure
2. Automate renewal via SCEP/MDM to prevent manual errors
3. Monitor expiration with alerts starting 60 days before
4. Test revocation regularly to ensure CRL/OCSP is working
5. Keep private keys secure -- use hardware security modules (HSM) where possible
6. Separate certificate roles -- do not reuse certificates across different purposes
7. Document your PKI -- maintain a diagram of your certificate hierarchy and trust relationships

Disaster Recovery

Prepare for certificate-related emergencies:

1. Compromised CA: Have a plan to rapidly revoke and reissue all affected certificates
2. Expired certificates: Maintain a list of all certificate expiration dates with automated alerts
3. Lost private keys: Keep secure backups of private keys (encrypted, offline storage)
4. Trust store corruption: Maintain golden images or MDM profiles to redeploy trust stores

Related Topics

• Certificate Revocation -- Revoking compromised or unnecessary certificates
• RadSec Configuration -- RadSec certificate setup
• Passpoint Onboarding -- Certificate deployment via onboarding
• WPA3-Enterprise -- WPA3 and certificate authentication
• Attributes -- RADIUS attributes for certificate-based sessions
• Data Governance and Compliance -- Compliance requirements for certificate management