This is what fascinated me too.

FWIW the idea of inspecting the certificate "for typos" or similar doesn't make sense. What you're getting from the CA wasn't really the certificate but the act of signing it, which they've already done. Except in some very niche situations your certificate is always already publicly available when you receive it, what you've got back is in some sense a courtesy copy. So it's too late to "approve" this document or not, the thing worth approving already happened.

Also the issuing CA was required by the rules to have done a whole bunch of automated checks far beyond what a human would reasonably do by hand. They're going to have checked your public keys don't have any of a set of undesirable mathematical properties (especially for RSA keys) for example and don't match various "known bad" keys. Can you do better? With good tooling yeah, by hand, not a chance.

But then beyond this, modern "SSL certificates" are just really boring. They're 10% boilerplate 90% random numbers. It's like tasking a child with keeping a tally of what colour cars they saw. "Another red one? Wow".

It's possible that this was just a slight imprecision of language, and the thing being inspected is the CSR rather than the actual certificate. (But the point about individual certificates/CSRs being unworthy of human attention is totally right.)

That's true, although inspecting a CSR is also daft because much of the CSR is actually ignored by the CA so you can "check" it but if it was "wrong" that makes absolutely no difference to anything.

The CA is going to look at the requested names (to check they were authorized) and they'll also copy the requested public key, this combination is what's certified. But if your antiquated gear spits out a CSR which also gives a (possibly bogus) company name and an (maybe invalid) street address "checking" that won't matter because the CA will just throw it away, the certificate they issue you isn't allowed to contain information they didn't check, so that part of your CSR is just tossed away without reading it.

There are CAs which to this day have been caught issuing certs that don't match CSRs, because the CA uses a manual process of hand-copy or hand-typing fields from the CSR into the new certificate.

So even reviewing CSRs won't help you.

(The solution of course is to automate your cert request/issuance, which has the side effect of ensuring no human is involved in the cert process)

There are environments where it's required that _every_ environmental change has an associated CCB ticket. In that kind of environment, yes, every new cert is attached to a ticket that the board has to review and approve.

Yes, it's insane, but it sure makes fault analysis easier when the environment is that locked down and documented.

But they don't require changes for altering the state of RAM on the server, or data in the database. So clearly not every change requires an associated ticket. Certificate renewal is part of the regular operation of a device, not a change to that operation.

It means that they click on the link in the email they get and confirm issuance for their domain that way.

Sounds so similar to something we had set up when I worked for a major retailer a few years ago. In order to get a cert you had to email the security team or some junk like that and THEY would go through the digicert UI. I stopped reading the absolutely giant and incredibly confusing certificate support document and swapped everything I was responsible for to ACM.

Side note, at some point I got an email telling me to stop issuing public certificates and only issue private certs. I had to get on a call with someone and explain PKI. To someone on the security team!