Stanford SSL Certificate Service FAQs

General

How long does it take to get a certificate?

For stanford.edu subdomains, certificates are issued immediately upon request. Because these domains are covered by DNS inheritance, domain validation is already satisfied

The process is fully automated:

You submit your CSR via https://certificate.stanford.edu/.
CERTInext confirms domain validation is already in place via DNS inheritance.
Your certificate is issued and emailed to your contact address.

For non-stanford.edu domains (e.g., hoover.org, lpch.net), the domain must be validated in CERTInext first before a certificate can be issued. See "My domain isn't validated in CERTInext" below. Once validated, issuance follows the same 15–30 minute timeline.

My certificate request failed -- what do I do?

Check the error message shown in the request form:

"You are not in NetDB for this hostname": You don't have administrator or user access to this hostname in NetDB. See "I got an error — you are not in NetDB" below.

"Domain has not been validated in CERTInext": Your domain needs DCV before a certificate can be issued. See "My domain isn't validated in CERTInext" below.

"NetDB check failed: Connection aborted": A transient network error occurred. Wait 30 seconds and try submitting again — this resolves itself automatically.

Still stuck? Contact ssl-team@lists.stanford.edu with your request ID (shown in the error message) and the hostname you were requesting.

My domain isn't validated in CERTInext — how do I validate it?

Non-stanford.edu domains must be validated in the CERTInext portal before a certificate can be issued. Stanford.edu subdomains are covered automatically via DNS inheritance and do not need manual validation.

To validate your domain:

Go to https://us.certinext.io and log in with Stanford SSO.
Navigate to Certificates → Discovery → Domains.
Find your domain in the list.
Click Validate and follow the DNS TXT record instructions.
Add the TXT record to your domain's DNS (via your DNS provider or NetDB).
Click Verify once the record has propagated.

Once validation is complete, return to https://certificate.stanford.edu/ and submit your certificate request normally.

For help with domain validation, contact ssl-team@lists.stanford.edu.

Can I request a wildcard certificate?

Yes, with restrictions:

Wildcard certificates are only available for stanford.edu subdomains (e.g., *.law.stanford.edu, *.dept.stanford.edu).
The base domain (e.g., law.stanford.edu) must exist as a Domain object in NetDB — not just a Node.
You must be listed as an owner in the NetDB Domain object, or be a member of a group assigned to it.
There must also be a NetDB Node for the base domain that passes the standard authorization check.

Wildcards for non-stanford.edu domains are not supported through this service. Contact ssl-team@lists.stanford.edu if you need one.

Where do I download my certificate after it's issued?

Your certificate is emailed to the contact address you provided when you submitted the request. The email includes direct download links.

You can also download it at any time from a stable, permanent URL:

For example:

This URL always returns the most recently issued certificate for that hostname. It is safe to bookmark and use in automation scripts.

What formats are available for download?

Three formats are available via query parameter:

Format	URL	Use this for
Full chain (default)	https://certificate.stanford.edu/cert/<hostname>	Apache, nginx, most web servers
Certificate only	https://certificate.stanford.edu/cert/<hostname>?type=cert	When you need just the end-entity cert
Intermediates + root only	https://certificate.stanford.edu/cert/<hostname>?type=chain	Java keystores, some legacy systems

Use the full chain for most web servers. Apache and nginx require the full chain (end-entity + intermediates + root) to serve certificates correctly. Serving just the end-entity cert will cause chain validation failures in some clients, particularly older browsers and mobile devices.

How do I renew an expiring certificate?

The process is identical to requesting a new certificate:

Generate a new CSR for your hostname (you can reuse your existing private key).
Go to https://certificate.stanford.edu/.
Submit the new CSR.
Download and install the new certificate once issued.

Certificates issued through this service have a 199-day validity period. We recommend renewing 30 days before expiry. You will receive an expiry notification email to your registered contact address as the renewal date approaches.

There is no automatic renewal — you must submit a new request each time. If you need fully automated renewal, contact ssl-team@lists.stanford.edu to discuss options (CertifiCat, ACME-capable server configurations, etc.).

I got an error "you are not in NetDB for this hostname" -- what does that mean?

Stanford's certificate service verifies that you are authorized to request a certificate for the hostname before issuing it. Authorization is checked in NetDB in the following order:

You are listed as a direct Administrator on the NetDB Node for that hostname.
You are a member of an admin team assigned to that NetDB Node.
You are listed as a User on the NetDB Node.
You are a member of a group assigned to the NetDB Domain object for that hostname.

If none of these apply, the request is denied.

What to do:

Look up your hostname in NetDB: https://netdb.stanford.edu/.
If the node exists and you should have access, ask an existing administrator to add you as an Administrator or User on that node.
If the node doesn't exist, it needs to be created in NetDB first -- submit a HelpSU ticket.
If you believe you already have access and are still seeing this error, contact ssl-team@lists.stanford.edu.

What happened to the old InCommon/certreq system?

The legacy Perl-based certificate request system (certreq.stanford.edu) and Stanford's InCommon/Sectigo certificate service were decommissioned on July 10, 2026 as part of Stanford's migration to CERTInext (emSign).

What changed:

The URL certificate.stanford.edu now points to the new Python-based certprovision service.
Certificates are now issued by CERTInext (emSign) instead of InCommon/Sectigo.
The process is faster and fully automated via ACME — no manual approval step.

What didn't change:

The URL you use: https://certificate.stanford.edu/ -- same as before.
The basic workflow: generate a CSR, submit it, receive the cert by email.
NetDB authorization requirements -- you still need to be listed in NetDB.

Certificates issued by the old InCommon system remain valid until their expiry date. When they expire, renew them through the new service.

If you have questions about the migration, contact ssl-team@lists.stanford.edu.