Artifact Signing Dlib 1.0.119: retry limits and billable signatures for one EXE

Question

Artifact Signing Dlib 1.0.119: retry limits and billable signatures for one EXE

Spencer Colety 0

For Windows SignTool with Azure.CodeSigning.Dlib.dll version 1.0.119, is there a documented, supported way to bound the number of billable signing operations for one invocation signing one ordinary PE .exe with SHA-256?

This excludes MSIX, batch signing, multiple input files, appended signatures and caller-initiated retries.

I'd like to confirm:

Whether this version has a supported setting to disable or cap internal signing-submission retries, and how to configure it.
The maximum submissions or billable signatures per invocation, including when the service accepts a request but its response is lost.
Whether internal retries reuse an idempotent operation or can create additional billable signatures.
Whether polling and timestamp requests are counted separately.

The integration guide describes CorrelationId, but I couldn't find a retry cap or an idempotency guarantee. Could you link version-specific documentation, or confirm if this version cannot provide that bound?

This is a general configuration question; no account-specific investigation or file upload is requested.

0 comments

2 answers

Your answer

Answer 1

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more

Answer 2

There is no publicly documented, supported configuration in Azure.CodeSigning.Dlib.dll 1.0.119 that guarantees an upper bound of one—or any specified maximum—billable signing submissions for a single SignTool invocation.

What is documented

The supported SignTool metadata fields are:

{
  "Endpoint": "<Artifact Signing account endpoint>",
  "CodeSigningAccountName": "<Artifact Signing account name>",
  "CertificateProfileName": "<certificate profile name>",
  "CorrelationId": "<optional workflow correlation value>"
}

The integration documentation defines CorrelationId as an opaque value for correlating signing requests with your workflows. It does not define it as an idempotency key, deduplication token, or retry identifier.^1^

The same documentation exposes authentication-selection controls through ExcludeCredentials, but it does not expose a signing-submission retry count, retry-disable switch, timeout-based submission cap, or equivalent setting.^1^

Consequently, for 1.0.119:

Disabling or capping internal signing retries: No supported setting is publicly documented.
Maximum service submissions per invocation: No maximum is publicly documented.
Lost response after server acceptance: No published contract says the Dlib can determine whether the first operation completed before resubmitting.
Idempotency: No published guarantee says retries reuse an existing signing operation or that CorrelationId deduplicates them.
Strict billable upper bound: It cannot be derived from the documented SignTool/Dlib contract.

A public question specifically reporting that CorrelationId was ignored has no accepted or recommended answer, so it does not establish additional semantics for that field.^2^

Billing, polling, and timestamping

Artifact Signing pricing is expressed in signatures per month, with additional per-signature pricing after the SKU quota.^3^ The FAQ says that the signing quota encompasses all signing activities across certificate profiles in an Artifact Signing account, but it does not define how duplicate submissions, retries, or ambiguous accepted requests are counted.^4^

The available documentation also does not state that status polling is a signature, nor does it explicitly specify its billing treatment. Therefore, polling should not be counted as an additional signature without confirmation from Microsoft, but it also cannot be excluded contractually using the published material.

Timestamping is a separate RFC 3161 request made by SignTool through /tr. Microsoft recommends its public timestamp authority because Artifact Signing certificates have a three-day validity.^1^ Artifact Signing also supports external timestamping services.^5^ Neither the integration documentation nor the billing FAQ says that timestamp requests consume Artifact Signing signature quota; however, no version-specific 1.0.119 billing guarantee is published for them.

Obtaining a supported bound

For a contractual or operational bound, open an Azure support request and ask Microsoft to confirm, specifically for Microsoft.ArtifactSigning.Client/Dlib 1.0.119:

The maximum number of signing-job creations per SignTool invocation.
Which failures trigger a new submission versus polling an existing operation.
Whether the operation identifier survives an accepted request whose response is lost.
Whether duplicate accepted submissions are deduplicated for billing.
Whether status polling or Microsoft timestamp-authority requests consume signing quota.

Include the Dlib version, SignTool version, SHA-256 PE scenario, SKU, region, and a sample CorrelationId; no binary upload should be necessary for this policy question. The Artifact Signing FAQ identifies Azure Support as the official support channel.^4^

Updating to the latest client is recommended by the integration guide, but it should not be treated as providing an at-most-once or billing-cap guarantee unless documentation for that version explicitly adds one.^1^

References