By the end of this article a cloud issuing authority sits beneath your own hierarchy, managed devices enrol certificates from it, every one of those certificates validates back to the root you built, and the template that made the signing possible has been removed again.
The ceremony itself is four commands and about ten minutes. Almost everything that goes wrong here goes wrong before it or after it.
Prerequisites. The hierarchy from [P 2.1] through [P 6.1], validating clean. Intune with an entitlement that includes Cloud PKI. Rights to publish a certificate template on the issuing authority and to create authorities and profiles in Intune. A test device enrolled in management that you can force a policy sync on.
Step 1. Check what the signature will freeze, and plan the trust delivery
Two things to settle before you sign anything. One is permanent and takes a minute. The other is the step people actually skip.
Whatever your issuing authority is configured with at this moment is what gets stamped into the cloud authority’s certificate, and it is frozen there for the whole of that certificate’s life. Correcting the configuration afterwards changes only what is issued from that point forward. So read it back and be sure you are content with it.
certutil -getreg CA\CRLPublicationURLs
certutil -getreg CA\CACertPublicationURLs
# and confirm the HTTP entries actually serve
certutil -URL "http://pki.catsnackjack.com/pki/CatSnackJack%20Issuing%20CA.crl"What you want to see is that the entries destined for issued certificates lead the list with an HTTP URL rather than a directory path. A Windows authority defaults to a directory location, which resolves for domain members and for nothing else, and HTTP is the only scheme every relying party in your estate can use. Intune surfaces whatever you stamped on the cloud authority’s properties page afterwards, which is a pleasant way to discover you left the default in place.
This is a permanence matter, not an availability one. An earlier version of this article told you to prove those URLs were reachable from the public internet before signing, on the grounds that managed devices would be fetching them. That was wrong. Managed devices do not fetch your chain, they are given it, which is the second thing to settle here.
Every certificate authority in your private chain needs a trusted certificate profile, for every platform you serve. A two-tier hierarchy means two profiles per platform before you have delivered a single end-entity certificate, and once the cloud authority exists you deliver its certificate the same way. Relying parties need the same material, by group policy for domain members and by hand for everything else, and the cloud authority’s certificate has to reach them too.
There is a documented fallback and you should not lean on it. If the cloud authority’s certificate is missing from a relying party, the chaining engine can retrieve it using the authority information access URL in the end-entity certificate, which is Microsoft’s endpoint rather than yours. Microsoft’s own guidance is that this behaviour is not guaranteed and varies by platform implementation, and Android does not perform that discovery at all. Deploy the certificates. The failure you avoid by doing so is the non-deterministic kind that works on the devices you tested and not on the ones you did not.
You can build the profiles for the private chain now, before the ceremony. The cloud authority’s own profile has to wait, because that certificate does not exist until step 4.
Step 2. Publish the subordinate template, temporarily
Signing a subordinate authority requires the Subordinate Certification Authority template to be published on your issuing authority. It is not published in normal operation, deliberately, because it grants the ability to obtain a certificate that can itself issue certificates.
certutil -SetCATemplates +SubCA
certutil -CATemplatesExpected result: six templates listed, the five from [P 5.1] plus SubCA. Note the time. This template is published for the duration of one signature and comes off again in step 5.
Step 3. Create the cloud issuing authority and take its request
In Intune, under tenant administration, create a certification authority and choose the bring-your-own option rather than a cloud root. Every property on this page is permanent.
| Setting | Value | Why |
|---|---|---|
| CA type | Bring your own CA (issuing) | Anchors to the hierarchy you already distributed trust for. A cloud root would mean repeating that exercise for a second chain. |
| Common name | CatSnackJack Cloud Issuing CA | Permanent, and appears in every device certificate. Make it obviously distinct from the on-premises issuing authority so a certificate dump is unambiguous. |
| Key size | RSA 2048 or higher | RSA only; there is no elliptic curve option. This value bounds what the SCEP profiles can request. |
| Extended key usages | Client Authentication, plus anything else you will ever need | The one that catches people. These cannot be added later. Needing another purpose means another authority, from a tenant budget of three. |
| Validity and hash | Not configurable | Inherited from whatever signs the request, which here means your issuing authority’s ceiling and SHA-256. That ceiling is one year, set when the authority was built, and it applies to a subordinate authority exactly as it applies to a web server. Step 4 raises it for the length of the signature and puts it back. |
Create it, then download the certificate signing request it generates.
Step 4. Sign it, and export the chain
Two things clamp the lifetime of what you are about to sign, and only one of them is a setting. The first is the authority’s own validity ceiling, which is one year, and which caps a subordinate authority exactly as it caps a web server. The second is the remaining life of the certificate this authority is holding. Nothing an authority signs can outlive the authority that signed it, so an issuing CA three years into a five-year certificate cannot produce a five-year subordinate no matter what any registry value says. Read both before you touch anything.
Both failures are silent. The signature succeeds, the certificate is valid, and it is simply shorter than you intended, which surfaces months later as Cloud PKI leaf certificates that cannot renew because their issuer is closer to expiry than their own renewal threshold.
# record the current ceiling before changing it
certutil -getreg CA\ValidityPeriod
certutil -getreg CA\ValidityPeriodUnits
# read this authority's own remaining life
certutil -ca.cert C:\temp\subca.cer
certutil -dump C:\temp\subca.cer
# raise the ceiling for the ceremony, then restart for it to take effect
certutil -setreg CA\ValidityPeriod "Years"
certutil -setreg CA\ValidityPeriodUnits 5
net stop CertSvc && net start CertSvcExpected result: the getreg calls return Years and 1, which is what you are about to change and what you will change back. The dump returns the issuing authority’s own NotAfter. If the gap between today and that date is shorter than the lifetime you want the cloud authority to have, raising the ceiling will not get it for you, and the real prerequisite is renewing this authority first, which is what [P 6.2] Build Sheet: Renewing the Issuing CA, and the Root is for. Failure mode to watch for: setting the values and not restarting the service. certutil -getreg will report the new value cheerfully while the running authority continues to issue on the old one.
Sign it from the command line. There is no web enrolment site on this authority, by the decision taken in the issuing CA build sheet, and the command line is shorter anyway. Export the chain in the same session, because Intune wants both the signed certificate and the chain file.
certreq -submit -attrib "CertificateTemplate:SubCA" `
-config "SUBCA\CatSnackJack Issuing CA" `
C:\temp\cloudpki.req C:\temp\cloudpki.cer
certutil -ca.chain C:\temp\fullChain.p7b
certutil -dump C:\temp\cloudpki.cerRead that dump before you upload anything. Confirm the issuer is your issuing authority, that the validity is what you expect given the ceiling you raised for the ceremony, and that the distribution point and authority information access extensions carry http://pki.catsnackjack.com/pki/ rather than a directory path. A directory path is not fatal here, because the chain reaches devices and relying parties by profile and by policy rather than by retrieval, but it is what you are stuck with for the life of this certificate and it is useless to anything that cannot reach a domain controller. If you are going to discard this and generate a fresh request from Intune, now is the only cheap moment to decide.
Put the ceiling back now, in the same session, while you are still thinking about it. This is the step that gets skipped, and skipping it leaves a production authority able to issue five-year certificates to anything with enrolment rights on a template that asks for them.
certutil -setreg CA\ValidityPeriod "Years"
certutil -setreg CA\ValidityPeriodUnits 1
net stop CertSvc && net start CertSvc
certutil -getreg CA\ValidityPeriod
certutil -getreg CA\ValidityPeriodUnits
certutil -dump C:\temp\cloudpki.cerExpected result: Years and 1 again, and a NotAfter on the signed certificate that matches what you intended. Check the dump rather than assuming, because this is the only moment the truncation is cheap to notice.
Then upload the signed certificate and the chain file in Intune. The authority moves to an active state.
Step 5. Remove the template again, now
certutil -SetCATemplates -SubCA
certutil -CATemplatesExpected result: back to five templates. Do this in the same session as the signing, not at the end of the project. The certificate took seconds to produce and the template’s purpose is complete. Left published, your issuing authority carries a standing offer to sign subordinate certificate authorities, which is the most powerful thing it can be asked for.
Step 6. Deliver trust, then the enrolment profile
Devices need every certificate in the chain above the leaf, delivered as trusted certificate profiles, one per certificate per platform. In this hierarchy that means three: the root, your on-premises issuing authority, and the cloud issuing authority whose request you just signed. Its certificate is downloaded from the Cloud PKI authority after activation and deployed the same way as the other two, one profile per certificate per platform.
Order matters. Trust profiles must reach a device before the enrolment profile does, or the device receives a certificate whose chain it cannot build. Assign the trusted certificate profiles to the same groups as the enrolment profile, which is the other half of the same mistake: a device that has one and not the other fails silently.
Then create the SCEP profile pointing at the cloud issuing authority, with the subject and alternative name construction your platform requires, key usage and size within the bounds set at creation, and the certificate validity you want. One caution carried from the on-premises side: do not mix enrolment service URLs and cloud authority URLs in a single profile.
Managed devices are not the only relying parties. The private chain reaches them through Intune, and everything else that will validate a certificate issued by the cloud authority has to acquire the same three certificates by whatever means already distributes trust in your estate, which for domain-joined systems means group policy. That population is your network access servers, your VPN concentrators and your internal services, and none of them are enrolled in Intune.
The end-to-end test
Sync a test device and let it enrol, then examine the certificate it received rather than trusting the profile’s reported status.
On the device, confirm the certificate exists, that its issuer is the cloud issuing authority, and that the chain builds all the way to the root you built in [P 2.1] with no gaps. Then do the part that actually matters: take the device off the corporate network entirely, onto a mobile connection, and authenticate with it against whatever it is meant to reach. That exercises the arrangement from the network position these devices normally occupy, and it is where a missing trusted certificate profile shows up, because the chain has to be complete on the device itself rather than assembled on demand.
The strongest single check is to fetch your root’s revocation list from that device’s network and confirm it retrieves and is in date. If that works, the whole arrangement works, because that file is the thing vouching for every layer above it.
A worked example: the purpose you forgot
An organisation creates a cloud issuing authority with client authentication as its only extended key usage, which covers the network authentication they are deploying this quarter. Six months later a project needs certificates for a VPN client that requires an additional purpose.
That purpose cannot be added. The authority’s properties were fixed at creation, so the answer is a second authority, which means a second signing ceremony, a second temporary publication of the subordinate template, a second trusted certificate profile per platform, and one more slot consumed from a tenant budget of three. Having used two, one remains, for the entire tenant, permanently.
The fix costs nothing at creation time and is impossible afterwards: enumerate every certificate use case the endpoint fleet might plausibly have in the next few years, and include those purposes now. This is the cloud equivalent of the permanent-decisions table from the first article in this series, with a smaller budget and the same asymmetry.
Rollback
Before devices have enrolled, rollback is clean: delete the profiles, delete the cloud authority, confirm the subordinate template is not published, and confirm the validity ceiling is back at one year. Nothing on your hierarchy was permanently altered, though the certificate you signed exists in your issued list and should be revoked so the record is honest. Take the ceiling seriously in a rollback: a run abandoned between raising it and restoring it is the one change here that outlives the rollback, and it leaves the authority able to issue five-year certificates to anything with enrolment rights on a template that asks for them.
certutil -view -restrict "CommonName=CatSnackJack Cloud Issuing CA" -out "RequestID,NotAfter"
certutil -revoke <request id> 5 # 5 = cessation of operation
certutil -crl
certutil -CATemplates # confirm SubCA is absent
certutil -getreg CA\ValidityPeriodUnits # confirm this reads 1, not 5After devices have enrolled, removing the cloud authority invalidates every certificate it issued, so treat it as a migration rather than a rollback: stop issuing, let certificates age out or reissue from elsewhere, then retire. And keep revocation for it published until the last certificate it signed has expired, exactly as you would for any authority you are decommissioning.
The signature you will perform again
Steps 2 through 5 are not a one-time ceremony, and this build sheet would mislead you if it left them looking like one. A bring-your-own issuing authority becomes eligible for renewal once it reaches half the validity its signer granted it, and renewing it is this same signature performed again against this same private authority. Intune produces a fresh certificate request, you sign it here, and you upload the result. Which means the subordinate template goes back onto the authority for the length of one signature and comes off again in the same session, exactly as it did in steps 2 and 5, for exactly the same reason.
What changed since this pattern first shipped is worth knowing, because it retires the strongest objection to anchoring a cloud authority to your own hierarchy. Renewal is staged rather than destructive. Choosing to renew produces a second version of the authority alongside the live one, carrying its own temporary enrolment URL, and you can point a test profile at that URL and prove issuance before committing to anything. When you activate it, the original production enrolment URL is restored. That is the detail that matters: the certificate profiles you deployed years earlier keep working untouched, and there is no round of profile surgery to schedule. The staged version waits ninety days for you to decide, lapses if you do not, and is deleted after a further thirty.
Two consequences for what you have just built. A renewal always generates a new key pair, because the previous one cannot be reused, so the renewed authority is cryptographically new while wearing the same name, and its display name gains a version suffix that says so. And renewal covers issuing authorities only. A cloud root cannot be renewed in place at all, which is one more argument for the decision this article took: the anchor with the twenty-five year life stays in your hierarchy, where the renewal path is yours to run and not a feature you are waiting on.
Put the date in the maintenance calendar from [P 6.1] now, while the reasoning is still fresh. It belongs next to the root’s annual appointment because it has the same shape: a task that is unremarkable when you are expecting it, and an outage when you are not.
Completion checklist
The issuing authority’s publication settings were read back before signing and lead with HTTP URLs rather than directory paths, and those HTTP locations serve. The cloud authority was created as a bring-your-own issuing authority with every extended key usage it will ever need. Its certificate was dumped and inspected before being uploaded. Both the certificate and the chain were uploaded. The subordinate template was published only for the signing and removed in the same session, verified by listing the published templates. The validity ceiling was raised for the signature and restored to one year in the same session, verified by reading it back rather than assumed. Trusted certificate profiles exist for every authority in the private chain and for the cloud authority itself, assigned to the same groups as the enrolment profile, on every platform in scope. Relying parties hold the same chain including the cloud authority’s certificate. A test device has enrolled, its chain builds to the root, and it authenticates from a network with no relationship to yours. The maintenance calendar from [P 6.1] records both the root’s annual revocation appointment and the date this cloud authority becomes eligible for renewal.
That last line is the whole point of this article, and it is where the series ends. You have built a hierarchy whose most important operational task is performed by hand, once a year, on a machine that is switched off. Everything else, including the part that lives in Microsoft’s cloud, depends on somebody remembering to do it.
On-Prem PKI
‹ Previous: [P 7] Where the On-Prem Estate Meets Cloud PKI
Next: [P 8] Post-Quantum Signing in AD CS: What ML-DSA Changes and What It Does Not ›
