cert-authority handling in authorized_keys broken

[Kegan Myers]

Anyone have thoughts or suggestions on this? Re-issuing all of the certs 
that are in use and working for hosts on older versions of openssh is a 
substantial effort.

Is there any chance of revisiting this issue, at least for this specific 
usage pattern?

On 8/30/26 4:53 AM, Kegan Myers via openssh-unix-dev wrote:
> I recently installed a machine that has a newer version of OpenSSH 
> server on it, and suddenly my certificates are being rejected. I have 
> been using a principal-less self-created PKI for years. That field 
> seemed superfluous for my use case of putting the CA in authorized_keys 
> (and not specifying principals= on that line either), as this was solely 
> for me on my machines/accounts. If I issued the cert (usually to a new 
> key or new device), I wanted it to just work wherever host I was 
> connecting to, and just drop it in the authorized_keys of "ubuntu", 
> "ec2-user", or even "root" in some cases.
> 
> It seemed like omitting the principal achieved exactly my goals and 
> worked perfectly fine. Documentation for how principals, and even certs 
> themselves seemed thin on the ground, so I was satisfied that using an 
> empty list was intended as a permissive wildcard. Even now the ssh- 
> keygen documentation mentions that a certificate includes "zero or more 
> principal (user or host) names" and only mentions wildcard characters as 
> being allowed for host keys.
> 
> Regardless, it was very surprising to suddenly have to debug a 
> "Permission denied" and see "Refusing certificate ...: Certificate lacks 
> principal list" in the server logs when trying to figure out what I had 
> done wrong. Previous discussion on this (https://marc.info/? 
> i=aSa3qSYgLlIRPs7m%20()%20wanda) identified exactly how I was using this 
> feature, but opted to reject all such certificates to prevent other bad 
> uses. The solutions to this regression I see are either a way to opt in 
> to old behavior (AllowEmptyUserCertificatePrincipals or similar) or to 
> only enforce principals being non-empty if some downstream check wants 
> to validate principals, though I am open to any suggestions as I am 
> certainly less familiar with the code base and how feasible those ideas 
> are than others on this list.
> 
> Best wishes,
> Kegan
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev