Summary
The help text for cert install describes its argument as a certificate "(PFX or CER)", but the implementation only ever loads PKCS#12. Passing a .cer fails with a raw cryptography error rather than a useful message. cert info has the same defect.
Repro
> winapp cert generate --publisher "CN=Contoso" --export-cer
> winapp cert info devcert.cer
Result: exit code 1, Cryptography_Der_Invalid_Encoding.
Verified against the bundled 0.6.0 CLI and a 0.6.1-pr dev build.
Cause
CertificateService.InstallCertificate uses X509CertificateLoader.LoadPkcs12FromFile for both the already-installed check and the install itself, so a DER-encoded .cer can never load:
https://github.com/microsoft/winappcli/blob/v0.6.1/src/winapp-CLI/WinApp.Cli/Services/CertificateService.cs#L130
ExtractPublisherFromCertificate (same file, ~L383) does the same, which is why cert info fails identically.
Why it matters
--export-cer exists precisely so a public certificate can be handed to someone else to trust. That recipient's natural next step is winapp cert install <the .cer> — which the help text tells them to do, and which does not work. Today the .cer is only usable via certutil / Import-Certificate, so the export has no supported path back into the CLI.
Options
- Make it true — load with
X509CertificateLoader.LoadCertificateFromFile when the file isn't PKCS#12, and install the public certificate into the trust store. This is the behaviour the help text already promises and the one that makes --export-cer self-consistent.
- Make the docs true — drop "or CER" from both help strings and fail a
.cer with a clear message ("expected a PFX; to trust a .cer use …") instead of a DER decoding error.
Option 1 seems more useful, but either is better than the current mismatch.
Downstream note
The WinApp VS Code extension (microsoft/WinAppVSCE) offered .cer in its certificate file pickers on the strength of this help text; those filters have been narrowed to .pfx to match the actual behaviour. If option 1 lands we'd be happy to widen them again.
Summary
The help text for
cert installdescribes its argument as a certificate "(PFX or CER)", but the implementation only ever loads PKCS#12. Passing a.cerfails with a raw cryptography error rather than a useful message.cert infohas the same defect.Repro
Result: exit code 1,
Cryptography_Der_Invalid_Encoding.Verified against the bundled 0.6.0 CLI and a 0.6.1-pr dev build.
Cause
CertificateService.InstallCertificateusesX509CertificateLoader.LoadPkcs12FromFilefor both the already-installed check and the install itself, so a DER-encoded.cercan never load:https://github.com/microsoft/winappcli/blob/v0.6.1/src/winapp-CLI/WinApp.Cli/Services/CertificateService.cs#L130
ExtractPublisherFromCertificate(same file, ~L383) does the same, which is whycert infofails identically.Why it matters
--export-cerexists precisely so a public certificate can be handed to someone else to trust. That recipient's natural next step iswinapp cert install <the .cer>— which the help text tells them to do, and which does not work. Today the.ceris only usable viacertutil/Import-Certificate, so the export has no supported path back into the CLI.Options
X509CertificateLoader.LoadCertificateFromFilewhen the file isn't PKCS#12, and install the public certificate into the trust store. This is the behaviour the help text already promises and the one that makes--export-cerself-consistent..cerwith a clear message ("expected a PFX; to trust a .cer use …") instead of a DER decoding error.Option 1 seems more useful, but either is better than the current mismatch.
Downstream note
The WinApp VS Code extension (microsoft/WinAppVSCE) offered
.cerin its certificate file pickers on the strength of this help text; those filters have been narrowed to.pfxto match the actual behaviour. If option 1 lands we'd be happy to widen them again.