Azure Artifact Certificate Expiry

Amit Rohatgi 0 Reputation points

Hi Team,

Based on our understanding from the meeting with last Support rep , it was mentioned that the certificate needs to be installed in the Trusted Publisher store only once.

However, the certificate we are currently using for signing files expires after three days. Once it expires, any new or modified files need to be signed using a newly generated certificate. In that case, the new certificate would also need to be installed in the Trusted Publisher store for the signed files to be trusted.

This means that each time a new certificate is generated and even a single file signed, we would need to share it with the client and have it installed on their machines. Over time, this could result in multiple certificates being added to the Trusted Publisher store, which may become difficult to manage and maintain.

Could you please confirm if our understanding is correct, or if there is an alternative approach that would allow us to avoid distributing and installing a new certificate every time the signing certificate changes?

 It would be great if we get on a call and have better understanding. Please schedule it for today or tomorrow IST.

  1. Sridevi Machavarapu 33,305 Reputation points • Microsoft External Staff • Moderator

    Hello Amit Rohatgi,

    Thank you for reaching out.

    Based on the information provided, additional clarification is needed to determine how trust is being established for your signed artifacts.

    While the signing certificates used by Artifact Signing have a short validity period and are renewed regularly, this does not necessarily mean that a new certificate must be distributed and installed on client machines each time a certificate is renewed. The required trust configuration depends on whether trust is established through the individual signing certificate or through the certificate chain.

    Could you please confirm the following:

    • How was the certificate initially added to the Trusted Publishers store?
    • Are you trusting the individual signing certificate or the issuing certificate chain?
    • Have you observed any trust issues with artifacts signed after a certificate renewal?

    Once we have this information, we can provide more specific guidance on the expected behavior and the recommended approach for managing trust.

  2. Amit Rohatgi 0 Reputation points

    Q.How was the certificate initially added to the Trusted Publishers store?

    A. We signed few PS1 files since execution policy is "All Signed" we needed to add Short lived Certificate in Trusted Public Store by right click it and install -Local Machine- Placed in Trusted Public Store.

    Q.Are you trusting the individual signing certificate or the issuing certificate chain?

    A. Currently we are adding individual signing certificate, we need help how to issue certificate chain in trusted publisher store.

    Q. Have you observed any trust issues with artifacts signed after a certificate renewal?

    A. We needed to sign few PS files after a gap of 7 days( these files signed by new Azure certificate obviously). But now these new files are giving trust issues with old certificate already installed in Trusted Publisher Store.

  3. Dawn-MSFT 80 Reputation points • Microsoft Employee

    Hello @Amit Rohatgi , for "we need help how to issue certificate chain in trusted publisher store", you can retrieve the signing certificate and certificate chain from the signature. Ensure the intermediate CA certificates are installed in the Intermediate Certification Authorities store so the chain can be validated, and, if required, add the publisher's signing certificate to the Trusted Publishers store.

    Please let us know if you need more information about the trusted publisher store.

  4. Amit Rohatgi 0 Reputation points

    As mentioned above we can not install short lived certificate on Trusted Publisher Store on Client Machine every time. As part of our understanding we have install "Subscriber identity validation Extended Key Usage (EKU) for durable identity pinning" . Are we correct on that to avoid installation of multiple short lived certificate? We need someone from your technical team to get on a call on with us to resolve this issue. Since we are already following up for last 3 days and it is for our production so highly critical for us. We are running out of time. We are available in IST hours from 9 AM to 9 PM IST, please schedule the call today ASAP.

  5. Dawn-MSFT 80 Reputation points • Microsoft Employee

    @Amit Rohatgi , Yes, you are correct regarding the EKU. The EKU is immutable and uniquely assigned to your profile.

    The intermediate CA certificates are "CN = Microsoft ID Verified Code Signing PCA 2021" and "CN = Microsoft ID Verified CS xxx xx xx" in the cert chain, not the leaf cert.

Sign in to comment

1 answer

  1. AI answer

    The understanding that a new end-entity code signing certificate must be distributed and installed in Trusted Publishers every three days is not correct for Artifact Signing.

    Key points from Artifact Signing behavior:

    1. Short‑lived end‑entity certificates are expected and intentional
      Artifact Signing issues short‑lived certificates that are renewed daily and valid for only 72 hours. This is by design to reduce the impact of misuse or abuse.
    2. Durable identity is provided via a custom EKU, not by pinning each certificate
      Because certificates are renewed daily, pinning trust to individual certificate thumbprints or public keys is not durable. Instead, Artifact Signing provides a subscriber identity validation EKU with OID prefix 1.3.6.1.4.1.311.97. that uniquely identifies the subscriber’s validated identity across all of its short‑lived certificates.
      All Artifact Signing Public Trust certificates also contain the Artifact Signing EKU 1.3.6.1.4.1.311.97.1.0 in addition to the standard code signing EKU 1.3.6.1.5.5.7.3.3.
    3. Trust is anchored at the CA / PCA level, not at each short‑lived certificate
      For scenarios such as ELAM and antimalware, Microsoft guidance is to:
      • Include the Artifact Signing PCA certificate TBS hash in the ELAM driver’s CertHash field, and
      • Include the vendor’s unique Artifact Signing EKU identity (the 1.3.6.1.4.1.311.97.* value) in the ELAM resource.
      This means the platform can trust all future short‑lived certificates issued under that PCA and associated with that EKU, without needing to install each new end‑entity certificate individually.
    4. Implication for Trusted Publishers / distribution
      In a properly configured environment that trusts the appropriate Microsoft root and intermediate CAs and uses the EKU‑based identity pinning model, there is no need to distribute and install a new end‑entity certificate every time Artifact Signing rotates it. The trust decision is made based on:
      • The CA chain (root/PCA) already trusted by the platform, and
      • The durable identity EKU that remains constant for the subscriber, even as individual certificates change.
    5. Operational model
      • The service performs zero‑touch certificate lifecycle management, including secure key management and daily renewals.
      • All issued certificates are logged in Azure (serial, thumbprint, created/expiry date, status), but these are for monitoring and revocation, not for per‑certificate distribution to clients.

    If the current implementation is pinning to each individual certificate (for example, by thumbprint in Trusted Publishers), that approach should be revised to align with the Artifact Signing model: trust the appropriate Microsoft CA chain and use the Artifact Signing EKU identity for durable identity pinning, rather than installing every short‑lived certificate.

    Scheduling calls or meetings is not supported; for deeper design or environment‑specific review, open a support request through Azure Support.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.
Sign in to answer

Your answer