Repository navigation
The default value for --end-date in az ad app create is misleading when using AsymmetricX509Cert #34233
Description
Describe the bug
When creting an app registration with an AsymmetricX509Cert as a credential, the default value for --end-date is Now+1 year even if the certificate has a greater expiration (e.g. 5 years). Even if the documentation states this clearly and correctly, the behavior is definetely different from the Azure Portal UI where there is no chance at all to choose a different keyCredential endDateTime when uploading a certificate.
Shouldn't the default behaviour when using certificates as credentials be to pick the certificate NotAfter as the keyCredential endDate?
Related command
az ad app create
Errors
The command doesn't fail, but the keyCredential created has a different endDate than the certificate used as a credential which sounds counterintuitive and misaligned with default Azure Portal UX.
Issue script & Debug output
N/A
Expected behavior
The keyCredential created, by default, should have an endDate equal to the certificate's NotAfter
Environment Summary
azure-cli 2.91.0
Additional context
No response
Activity
yonzhan commentedon Oct 16, 2026
Thank you for opening this issue, we will look into it.
microsoft-github-policy-service commentedon Oct 19, 2026
🔔 Routing this issue to @Azure/act-identity-squad.
x-engineering-agent commentedon Oct 19, 2026
The current
az ad app createimplementation passes--end-dateinto_build_key_credentials. When it is omitted, that builder uses the start date plus one year minus 24 hours for every key type, includingAsymmetricX509Cert; it does not inspect the certificate's NotAfter value (create path, date default and credential body). The argument help documents the approximately one-year default. This explains the mismatch with the Portal rather than indicating an error in certificate parsing.For now, pass
--end-dateexplicitly with your certificate's NotAfter timestamp (for example, in2029-01-01T00:00:00+00:00format) when supplying--key-value; the CLI will use that date for the key credential. Changing the default for certificate credentials would change existing CLI behavior, so the identity maintainers should decide whether and how to introduce that behavior rather than treating it as a safe automatic bug fix.Posted by x-engineering-agent (Fixer)
x-engineering-agent commentedon Oct 19, 2026
The current
az ad app createbehavior follows its documented default:--end-datedefaults to one year after the current time. In the key-credential builder, an omitted end date is computed from the start date (roughly one year, minus 24 hours); the certificate'sNotAfteris not read from--key-value.To make the key credential expire with your certificate today, pass its
NotAfterexplicitly using--end-date(for example, a UTC datetime with+00:00). Automatically deriving that date for certificates would change the documented default, so this is a request for the identity command maintainers to assess as an enhancement, rather than a regression fix.Posted by x-engineering-agent (Fixer)
microsoft-github-policy-service commentedon Oct 20, 2026
🔔 Routing this issue to @Azure/act-identity-squad.
x-engineering-agent commentedon Oct 20, 2026
The current behavior matches the documented default, but I agree the difference from a certificate's validity period is worth considering. For
az ad app create, the--end-datehelp says the default is one year after the current time. The credential builder sets the key credential'sendDateTimefrom--end-date, or to approximately one year from its start if omitted; it does not derive the date from the certificate. This is a request to change the default, not evidence of a failing command.To align a credential with a certificate today, pass its NotAfter date explicitly using
--end-date(in UTC). I'll leave the proposed certificate-aware default with the identity maintainers to evaluate, including compatibility with existing scripts and the behavior for other key types. No automated fix is queued for a default change without that design decision.Posted by x-engineering-agent (Fixer)