TL;DR: Yes, same as when not using certificates
Whether or not you need a passphrase depends (like so much in security) on your threat model, environment, and use case. The purpose of the passphrase is to protect the private key (at least for a while) if it gets exposed to a malicious user. This has nothing to do with using certificates or not, from the user's perspective; whether the public key is wrapped in a certificate or not is irrelevant to the private key. However, when using certs the CA private key in particular wants a passphrase especially strongly, since it's extra-sensitive because CA private keys are used to issue new certs that are typically trusted by lots of computers.
On the other hand, if you're using a private key that never leaves your computer, on a computer never used by another person, running only code you fully trust, and with its storage encrypted (Bitlocker / File Vault / Veracrypt / other full-volume encryption) and/or the device physically protected (e.g. inside a secured facility), then adding a passphrase to it might add more inconvenience than the marginal benefit to security is worth. If you're using the private key in a way that requires it to be accessible to automation with no human available to input the passphrase, then that's another reason you might leave it off since otherwise the passphrase has to be stored in plain text on the system somewhere. Finally, if you're storing the private key in a key management system or other encrypted store, which requires authentication to even access, you might not bother having a custom passphrase on the key itself since the KMS / encrypted store should protect it.
Certificates vs. bare keys only concern the public key, and passphrases only concern the private key. In the context of "cert vs. bare key", passphrases are irrelevant.
The only things ssh certificates do are:
- Provide a way to verify public key correctness other than "trust on first use"
- Identify who a public key is for (other than using the file name)
- Support public keys expiring automatically (or possibly being revoked early)
The only things passphrase protections on SSH private keys do are:
- In the event a malicious user sits down at a victim's computer, they can't use the private key (creating a pseudo-2FA protection)
- In the event a private key is exposed / stolen, there's a window of time where the attacker can't use it (they need to crack the passphrase first) during which the victim can revoke and re-issue the corresponding public key (or cert containing said public key) without getting compromised
- (For CA private keys) even if the CA key file is exposed or shared, only authorized users can sign new certificates (the same applies to using non-CA private keys, but those are usually inherently one-per-user in a way CA keys aren't)
It's worth noting that, on Windows and MacOS, the private key file can be protected using platform key storage / encryption (DPAPI or EFS on Windows; Keychain on Mac) and this storage encrypts the private key contents with a key derived from the user's password. Linux has no such feature, so unless you add your own passphrase the private key file is only protected by file system permissions / ACLs, and potentially by full-volume encryption (which is available on all major OSes but only protects the data at rest or when the drive is connected to an attacker's OS). On the other hand, you might add a passphrase to the file created by
ssh-keygen anyhow, then later import it into the platform key storage and remove the key-specific passphrase on the imported key.