VSoft Technologies Blogs

Signotaur 2.1: signing documents, not just code

Thu, 06 Aug 2026 03:19:46 GMT

In this article:

Signing PDF, XML and other documents with Signotaur
PAdES, XAdES and CAdES signature formats
Baseline, timestamped, long-term and archival signatures
Document-signing certificates and trust
Other changes in Signotaur 2.1

Until now, Signotaur has concentrated on code signing. Version 2.1 adds document signing, using the same client, server and key-custody model. It can sign PDFs, XML files and other data in the standard formats used by document viewers, business systems and archives. The private key remains on the Signotaur server, hardware token or HSM at all times.

Document signing is included in the Enterprise edition. Code-signing features remain available under the Standard licence.

PAdES, XAdES and CAdES

Different document types store signatures in different ways. Signotaur supports three ETSI Advanced Electronic Signature formats:

PAdES is used for PDF files. The signature is added as an incremental update without rewriting the existing PDF content, and the file continues to open normally in PDF readers. Signotaur selects PAdES automatically for .pdf files.
XAdES is used for XML. By default, the signature is added inside the XML document alongside the content it covers. A detached signature can be written separately when the original XML must remain unchanged. Signotaur selects XAdES automatically for .xml files.
CAdES can sign other types of content, such as CSV or JSON data, images and archives. Pass --format cades to create a detached .p7s signature beside the original file.

All three are established standards, so signatures created by Signotaur are not tied to Signotaur for verification. They can also be checked by compatible third-party software, including PDF readers that support PAdES.

Choosing a signature level

A plain signature proves who signed the content and that it has not changed. It does not prove when it was signed, or that the signing certificate was valid and unrevoked at that moment. Once the certificate expires, a verifier has little to go on. The --level option chooses how much supporting evidence to include. The same four levels are available across all three formats, and each includes everything from the levels below it:

baseline includes the signature and signing certificate. This is the default.
timestamped adds an RFC 3161 timestamp from a timestamp authority. This establishes when the signature existed without relying on the signer's computer clock, allowing a verifier to see that it was created within the certificate's validity period.
long-term also embeds the certificate chain and revocation evidence, using OCSP responses or certificate revocation lists (CRLs). This allows the evidence to be checked later without depending on the issuing CA's services still being available.
archival adds another timestamp over the signature and its supporting evidence, recording that the complete package existed intact while its algorithms were still considered secure.

Levels above baseline require a timestamp authority, supplied with --timestamp-server. For long-term and archival signatures, Signotaur collects revocation evidence while signing. If it cannot retrieve that evidence, it identifies the affected certificate and continues with a warning. The signature remains valid, but may not be verifiable offline or after the certificate expires.

Signing a document

Document signing uses the existing sign command. For a PDF, the simplest form looks like this:

SignotaurTool.exe sign -a [APIKey] -s [SignServer] -t [Thumbprint] contract.pdf

To add a timestamp, select the timestamped level and provide a timestamp authority:

SignotaurTool.exe sign -a [APIKey] -s [SignServer] -t [Thumbprint] --level timestamped --tr http://timestamp.example.com contract.pdf

The signed PDF replaces the input file, so retain the original separately if it is still required.

PDF signatures are invisible by default: the signature is available through the reader's signature panel, but nothing is drawn on the page. Signotaur can instead add a visible signature containing a reason, location and optional logo. A password-protected PDF can also be signed: supply the password needed to open it and the file stays encrypted afterwards.

Verifying document signatures

The existing verify command recognises PAdES, XAdES and CAdES as well as the code-signing formats already supported by Signotaur:

SignotaurTool.exe verify contract.pdf invoice.xml invoice.csv.p7s

Signotaur detects the signature format, including an XML document accompanied by a detached signature, and reports whether each file's signature was verified.

Document-signing certificates

Code-signing and document-signing certificates are marked for different purposes. Signotaur checks that marking before a signing run begins, so a code-signing certificate cannot normally be used to sign a document, or vice versa.

An existing document-signing certificate can be registered from a PFX file, the Windows certificate store, or a hardware token or HSM accessed through PKCS#11. When a hardware device is used, the private key remains on that device and Signotaur asks it to perform the signing operation.

A document-signing certificate can also be issued through Signotaur's Internal CA or Microsoft AD CS. Select Document signing as the purpose in the Issue dialog. Certificates issued by the Internal CA carry the Microsoft, Adobe and RFC 9336 document-signing usages for compatibility with a broad range of verifiers.

Certificates registered before upgrading to 2.1 remain recorded as code signing. Re-register any certificate that should also be available for document signing.

Certificate trust

Creating a valid signature does not automatically make its certificate trusted by every recipient. Trust is decided by the software or system performing the verification.

Adobe Acrobat, for example, trusts a signature when its certificate chains to a root that Acrobat trusts. That may be a public root on the Adobe Approved Trust List, or a private root installed by your organisation. Certificates issued by Signotaur's Internal CA are therefore well suited to documents used within an organisation that distributes and trusts its own root certificate. Documents sent outside that environment may need a certificate from a publicly trusted provider.

Trust and revocation are separate concerns. If signed documents leave your network, Signotaur 2.1 can publish the Internal CA's revocation list and issuer certificate to an external location. Recipients can then check whether a certificate has been revoked without needing access to your internal network. This does not make the Internal CA publicly trusted; recipients must still trust its root separately.

A trusted certificate is also not necessarily a qualified certificate in the eIDAS sense, a distinction covered in the documentation.

Using document signing in a pipeline

Because document signing uses the existing Signotaur client and API-key authentication, it can be added to the same release and automation processes as code signing. A release can sign its executables and accompanying PDF documentation, while another job might sign generated invoices or XML messages.

The build machine never receives the private key. Access remains controlled through Signotaur, and successful and failed signing requests are recorded in its audit trail.

Also in Signotaur 2.1

Document signing is the main addition, but version 2.1 also includes several changes to the Internal CA and certificate management:

Validation Authority. The Internal CA can answer OCSP requests and publish CRLs and CA certificates, allowing the status of certificates it issues to be checked.
Multiple Intermediate CAs. Intermediates can be scoped to web (TLS), code signing, document signing or all purposes, and managed independently.
Certificate identities and policies. Issued certificates can carry structured subjects and identify the certificate policy under which they were issued.
Certificate-management improvements. These include a Certificate authorities view, whole-chain downloads and renewal under the Intermediate CA that originally issued the certificate.
Certificate-purpose enforcement. If a certificate is unsuitable for any artefact in a batch, the run fails before anything is signed. Pass --warn-wrong-purpose to warn and sign anyway.

Summary

Signotaur 2.1 brings PDFs, XML and other documents into the same controlled signing process already used for software. It supports the standard PAdES, XAdES and CAdES formats, four levels of signing evidence, visible PDF signatures and certificates issued internally or registered from an existing source.

The private key remains in its controlled location, whether that is the Signotaur server, a hardware token or an HSM. Existing deployment and automation processes can use the same client and API-key model they already use for code signing.

Full details are available in the Signotaur 2.1 documentation, including Signing Documents, Document Signing Certificates and the sign command reference.

See the Signotaur 2.1 release announcement for the full changelog. To evaluate document signing on an existing installation, request a 14-day Enterprise trial licence from the Licences page in the server administration interface.

Signotaur 2.0: managing certificates, not just signing with them

Fri, 26 Jun 2026 01:39:43 GMT

In this article:

Signing PDF, XML and other documents with Signotaur
PAdES, XAdES and CAdES signature formats
Baseline, timestamped, long-term and archival signatures
Document-signing certificates and trust
Other changes in Signotaur 2.1

Document signing is included in the Enterprise edition. Code-signing features remain available under the Standard licence.

PAdES, XAdES and CAdES

Different document types store signatures in different ways. Signotaur supports three ETSI Advanced Electronic Signature formats:

PAdES is used for PDF files. The signature is added as an incremental update without rewriting the existing PDF content, and the file continues to open normally in PDF readers. Signotaur selects PAdES automatically for .pdf files.
XAdES is used for XML. By default, the signature is added inside the XML document alongside the content it covers. A detached signature can be written separately when the original XML must remain unchanged. Signotaur selects XAdES automatically for .xml files.
CAdES can sign other types of content, such as CSV or JSON data, images and archives. Pass --format cades to create a detached .p7s signature beside the original file.

Choosing a signature level

baseline includes the signature and signing certificate. This is the default.
timestamped adds an RFC 3161 timestamp from a timestamp authority. This establishes when the signature existed without relying on the signer's computer clock, allowing a verifier to see that it was created within the certificate's validity period.
long-term also embeds the certificate chain and revocation evidence, using OCSP responses or certificate revocation lists (CRLs). This allows the evidence to be checked later without depending on the issuing CA's services still being available.
archival adds another timestamp over the signature and its supporting evidence, recording that the complete package existed intact while its algorithms were still considered secure.

Signing a document

Document signing uses the existing sign command. For a PDF, the simplest form looks like this:

SignotaurTool.exe sign -a [APIKey] -s [SignServer] -t [Thumbprint] contract.pdf

To add a timestamp, select the timestamped level and provide a timestamp authority:

SignotaurTool.exe sign -a [APIKey] -s [SignServer] -t [Thumbprint] --level timestamped --tr http://timestamp.example.com contract.pdf

The signed PDF replaces the input file, so retain the original separately if it is still required.

Verifying document signatures

The existing verify command recognises PAdES, XAdES and CAdES as well as the code-signing formats already supported by Signotaur:

SignotaurTool.exe verify contract.pdf invoice.xml invoice.csv.p7s

Signotaur detects the signature format, including an XML document accompanied by a detached signature, and reports whether each file's signature was verified.

Document-signing certificates

Certificates registered before upgrading to 2.1 remain recorded as code signing. Re-register any certificate that should also be available for document signing.

Certificate trust

Creating a valid signature does not automatically make its certificate trusted by every recipient. Trust is decided by the software or system performing the verification.

A trusted certificate is also not necessarily a qualified certificate in the eIDAS sense, a distinction covered in the documentation.

Using document signing in a pipeline

The build machine never receives the private key. Access remains controlled through Signotaur, and successful and failed signing requests are recorded in its audit trail.

Also in Signotaur 2.1

Document signing is the main addition, but version 2.1 also includes several changes to the Internal CA and certificate management:

Validation Authority. The Internal CA can answer OCSP requests and publish CRLs and CA certificates, allowing the status of certificates it issues to be checked.
Multiple Intermediate CAs. Intermediates can be scoped to web (TLS), code signing, document signing or all purposes, and managed independently.
Certificate identities and policies. Issued certificates can carry structured subjects and identify the certificate policy under which they were issued.
Certificate-management improvements. These include a Certificate authorities view, whole-chain downloads and renewal under the Intermediate CA that originally issued the certificate.
Certificate-purpose enforcement. If a certificate is unsuitable for any artefact in a batch, the run fails before anything is signed. Pass --warn-wrong-purpose to warn and sign anyway.

Summary

Full details are available in the Signotaur 2.1 documentation, including Signing Documents, Document Signing Certificates and the sign command reference.

Signing files that can't carry a signature: detached CMS for ZIPs, ISOs and more

Fri, 12 Jun 2026 02:25:05 GMT

In this article:

Why some files can't carry an embedded signature
What a detached .p7s signature is, and when Signotaur writes one
Signing archives and disk images with no extra flags
Extending detached signing to arbitrary files with --detached
Controlling the output path, and verifying with Signotaur or OpenSSL

Most of the file types Signotaur signs have somewhere to put the signature. A PE binary has a certificate table, an MSI has a digital-signature stream, a NuGet package has a reserved ZIP entry. You sign the file, the signature goes inside it, and the file still works exactly as before.

Plenty of files people need to sign have no standard embedded-signature format. A .zip, a .tar.gz, an .iso, a firmware blob, a plain .json manifest — several of these do have comment or metadata areas you could stash bytes in, but there's no agreed-upon signing format that other tools would recognise. You can wrap the whole file inside a signature structure, but that changes the file itself: your zip is no longer a zip, it's a CMS structure containing the zip.

The standard answer to this is a detached signature: sign the bytes, leave the original artifact untouched, and write the signature to a separate file. Signotaur now supports this directly, producing a standard CMS/PKCS#7 .p7s signature next to the file it signed.

CMS (Cryptographic Message Syntax, RFC 5652) is the IETF standard format for digitally signed data; PKCS#7 is the older format CMS was based on, and the names are still often used interchangeably. The .p7s extension is the conventional one for a detached CMS signature, which is why you'll see it throughout this post.

Archives and disk images: nothing to do

Signing a zip while keeping it usable is by far the most common case, so Signotaur automatically uses detached signatures for common archive and disk-image formats, with no extra flags:

SignotaurTool.exe sign -a [APIKey] -s [SignServer] -t [Thumbprint] release.zip

That signs release.zip and writes the signature to release.zip.p7s alongside it. release.zip itself is not touched — same bytes, same hash, still opens in any zip tool. The formats handled this way are .zip, .7z, .tar, .gz, .tgz, .bz2, .xz, .iso, .img, .vhd and .vhdx.

Files that do have a native embedded format — PE, MSI, NuGet, VSIX, RDP, ClickOnce manifests, .mobileconfig — keep using it. You don't have to think about which is which; the sign command routes each file by its type.

Other file types: `--detached`

To produce a detached signature for a file type that Signotaur would not otherwise sign as an embedded format — for example a .txt, a .json, an arbitrary binary — add --detached (--dt):

SignotaurTool.exe sign -a [APIKey] -s [SignServer] -t [Thumbprint] --detached manifest.json

This writes manifest.json.p7s and leaves manifest.json alone. The flag is ignored for file types that have their own embedded signature, so it's harmless to leave on in a script that signs a mix of things.

Choosing where the signature lands

By default the signature is written next to each signed file as [file].p7s. To put signatures somewhere else, use --signature-file (--sf). For a single file you can give an exact path:

SignotaurTool.exe sign release.zip --signature-file C:\sigs\release.sig ...

When signing many files at once, use placeholders so each output is distinct:

{name} — the file name including extension (archive.zip → archive.zip.p7s).
{name-no-ext} — the file name without extension (archive.zip → archive.p7s).
{rel-path} — the file path relative to the current directory, or to --base-directory if specified. This avoids collisions when different folders contain files with the same name.

SignotaurTool.exe sign src\**\*.zip --signature-file sigs\{rel-path}.p7s ...

Any directories in the output path are created for you. An exact (placeholder-free) path is only valid when signing a single file — otherwise every file would write to the same signature file.

Verifying

A .p7s file is a plain CMS/PKCS#7 SignedData structure, so it's not locked to Signotaur. Point verify at either the original or its .p7s signature and it auto-detects the pairing:

SignotaurTool.exe verify release.zip

And because it's standards-compliant, OpenSSL — or anything else that speaks CMS — can verify it too:

openssl cms -verify -binary -inform DER -in release.zip.p7s -content release.zip -CAfile root.pem -out NUL

That example assumes a signer certificate issued directly by the root in root.pem; in practice, use whichever CA bundle or certificate chain is appropriate for the signer certificate. (-out NUL just discards the recovered content so the zip isn't dumped to the console.)

If you only need an integrity check — confirm the signature matches the content, without deciding whether the signer is trusted — add -noverify. It skips chain validation, so no root.pem is required:

openssl cms -verify -noverify -binary -inform DER -in release.zip.p7s -content release.zip -out NUL

This confirms the bytes haven't changed since signing, but it does not establish that you trust the signer — for that, use the chain-validating form above.

RFC 3161 timestamping works on detached signatures the same as everywhere else — pass --tr (and optionally --st) and the timestamp is embedded into the .p7s.

Wrapping up

Detached signing extends Signotaur beyond formats with a built-in signature slot. Where a file has a native signing format, Signotaur continues to use it. Where it does not, Signotaur can write a clean .p7s signature alongside the untouched original.

The result is still standards-compliant CMS/PKCS#7, so consumers are not tied to Signotaur for verification. More to come, but this removes a "you can't sign that" answer we'd rather not give.

For the full option reference see the sign and verify command pages in the Signotaur documentation. As always, the private key never leaves your signing server — detached or embedded, only the digest is ever sent for signing.

Signing .rdp files with Signotaur (and surviving the April Windows update)

Fri, 24 Apr 2026 02:27:48 GMT

In this article:

What changed for signed .rdp files in the April 2026 Windows update
Why previously-working signatures now show an orange warning dialog
The registry policy recipient machines need for no dialog at all
How Signotaur signs .rdp files without distributing the certificate
Deploying the policy via Group Policy or PowerShell

If you push Remote Desktop shortcuts out to users, you probably already know about the April 2026 Windows cumulative update (KB5083769 on Windows 11, KB5082200 on Windows 10). If you don't, you might have found out the hard way — via a Monday-morning deluge of "is this a virus?" tickets from users who suddenly have a big orange warning on the RDP file that worked fine last week.

Signotaur 1.2.0.107 ships with .rdp file signing support. Here's what changed in Windows, why it matters, and what the new signing command actually does.

What Microsoft changed

The April cumulative addresses CVE-2026-26151. Two user-visible things came with it:

The Remote Desktop Connection warning dialog was redesigned. It now lists every resource the connection can redirect (drives, printers, clipboard, USB, etc.) with individual checkboxes, and every box is off by default. Users have to opt in to each one on every connection, every time.
The trust criteria for signed .rdp files tightened. Pre-April, a file signed by an untrusted cert got a yellow "Verify the publisher" banner. Post-April, the same file gets an orange "Caution: Unknown remote connection" banner — visually indistinguishable from an unsigned file.

Here's what the new per-launch dialog looks like. For an unsigned file:

And for a file signed by a publisher Windows can verify:

Separately, the first time any user opens an .rdp file after installing the update, Windows shows a one-time educational dialog explaining what .rdp files are and why they can be dangerous:

Once dismissed, it doesn't reappear for that account.

Discussion and lament: r/sysadmin: FYI: Microsoft RDP changes with April cumulative.

This is a genuinely good security change — the old dialog was vague and under-informed users about what was being shared with the remote host. It is also a rather annoying deployment change, because plenty of teams had rdpsign.exe-signed files quietly working for years, and now they don't.

Why people got caught out

The usual story goes like this: a team signed their .rdp file years ago with a self-signed or internal-CA certificate, shipped it to users, and it displayed a friendly yellow "Verify the publisher: Acme Corp" dialog that everyone clicked through. After April's update, the same file suddenly shows an orange "Unknown remote connection" dialog and support gets flooded. One representative example from the Reddit threads: a sysadmin describing exactly this.

The signatures on those files are still cryptographically valid. Windows is just stricter now about what counts as a "verified publisher" for RDP.

The actual recipe (no dialog at all)

Cutting through the noise, here's what recipient machines need for a signed .rdp file to open with no warning dialog at all:

The signing certificate's chain must terminate in a root the client machine trusts. Commercial code-signing certs (DigiCert, Sectigo, etc.) chain to roots Windows already trusts. For an internal CA or self-signed cert, the root has to be imported into Cert:\*\Root on each client.
A Remote Desktop trust policy must be in place that whitelists your signing certificate's SHA-1 thumbprint. This lives at either HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services (machine-wide, requires admin) or HKCU\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services (per-user, no admin required), and needs two values:
- AllowSignedFiles — REG_DWORD, set to 1
- TrustedCertThumbprints — REG_SZ, the SHA-1 thumbprint of your signing cert, uppercase, no spaces (semicolon-separated if you have more than one)

A word of warning about one trap we hit: TrustedCertThumbprints is a whitelist on top of normal chain validation, not a replacement for it. Dropping a self-signed cert's thumbprint into the list without also importing the cert into a trusted root store does nothing. If you've tried this and wondered why it didn't work, that's why.

What Signotaur does when you sign a .rdp file

Unlike rdpsign.exe, Signotaur signs .rdp files against a remote server — the private key stays on the server (or an HSM it's connected to), so no admin workstation or automation host needs a local copy of the signing certificate. This is the main reason to use Signotaur for .rdp signing rather than running rdpsign.exe directly.

The mechanics otherwise match what you'd expect. The client reads the .rdp file, canonicalises the contents, sends only the digest to the server for signing, and writes the signed file back in place. The output is byte-equivalent to rdpsign.exe's — same canonical form, same 12-byte Microsoft wrapper, same detached CMS structure — so recipients see the same Windows Remote Desktop Connection dialog regardless of which tool produced the signature.

RFC 3161 timestamping is supported, and the timestamp is embedded into the CMS in the standard way. But there's a caveat that's easy to miss: mstsc.exe doesn't actually consult the timestamp when validating a .rdp signature — it only checks whether the signing certificate is currently valid at the moment the file is opened. The strongest indirect evidence for this is that Microsoft's own rdpsign.exe has no timestamping support at all — no /tr flag, no timestamp in its output.

The timestamp is still worth having: it's standards-compliant CMS so general-purpose tools can read the signing time, it provides a tamper-evident audit trail, and it future-proofs against any future change in mstsc's behaviour. In practice though, plan to re-sign distributed .rdp files when your signing certificate is renewed, the same way you would for an unsigned-but-distributed file.

Because the registry recipe above is easy to get wrong, Signotaur also prints the recipe for you after signing, pre-filled with the thumbprint of the certificate that just signed the file. It tells you whether the cert is self-signed (in which case you'll also need to deploy the cert itself to recipient trusted-root stores) or chained (in which case you may not).

If you're running sign interactively on Windows, it also offers to apply the policy to HKCU for the current user on the spot — no admin rights needed, no registry editor, no PowerShell snippet to copy-paste. This is mostly useful for confirming the signing works locally before you deploy the policy via GPO. In unattended runs, the prompt is automatically skipped, and you can pass --no-mstsc-guidance (--nmg) to suppress the whole lot if the log gets noisy.

An example

The sign command detects .rdp files automatically based on extension, so there's nothing special to type:

	
			SignotaurTool.exe sign -a  -s  -t  --tr http://timestamp.digicert.com --td SHA256 connect-to-prod.rdp

After a successful sign you'll see something along the lines of:

RDP signing guidance (Windows Remote Desktop Connection compatibility, post-KB5083769):

By default recipients will see a "Verify the publisher" or "Unknown publisher"
warning dialog when opening this signed file in Windows Remote Desktop Connection.
To eliminate the warning, each recipient machine needs:

1. The signing certificate's chain trusted on the machine.
   For commercial certificates chaining to a Windows-preinstalled root, no action
   is required; internal-CA certificates require the CA to be imported into each
   recipient's Trusted Root store.

2. The signing certificate's thumbprint added to the Remote Desktop trust-publisher
   policy:

   Value: AllowSignedFiles (REG_DWORD) = 1
   Value: TrustedCertThumbprints (REG_SZ) = 

Apply AllowSignedFiles + TrustedCertThumbprints to your current user registry now?
Useful for testing this signed .rdp locally. [y/N]:

Answer y and it writes the values to your HKCU — open the file in Remote Desktop Connection, confirm there's no dialog, and you know the signing bit is working before you take the policy near a GPO.

Deploying the policy to the fleet

For anything beyond a couple of machines, Group Policy is the right tool — it's also how you set these same values without touching the registry by hand. In the Group Policy Management Editor:

Computer (or User) Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Connection Client
Allow .rdp files from valid publishers and user's default .rdp settings → Enabled
Specify SHA1 thumbprints of certificates representing trusted .rdp publishers → Enabled, with your thumbprints in the list (uppercase, semicolon-separated if multiple)

Intune has equivalent settings under the Administrative Templates profile. If you're deploying to a smaller set of machines, or scripting it, a PowerShell snippet that does the per-user version (no admin needed) looks like this:

	
			$p = 'HKCU:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services'
New-Item -Path $p -Force | Out-Null
Set-ItemProperty -Path $p -Name AllowSignedFiles -Value 1 -Type DWord
Set-ItemProperty -Path $p -Name TrustedCertThumbprints -Value 'YOUR_THUMBPRINT_UPPERCASE' -Type String

Swap HKCU for HKLM for the machine-wide version (and run elevated). The thumbprint must be uppercase with no spaces; use a semicolon to join multiple thumbprints if you have more than one signing cert in rotation.

What you still can't do

A few things worth knowing up front so you don't hunt for them:

The per-redirection checkboxes in the new dialog are not controlled by AllowSignedFiles. Even with a properly trusted and whitelisted signature, users still see the redirection dialog on first use. There's a separate set of policies for which redirections are allowed on the server side; the client-side checkboxes are a user-consent UI rather than a trust decision.
There's a temporary "revert to pre-April dialog" switch at HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services\Client\RedirectionWarningDialogVersion = 1. Don't rely on it — Microsoft has been explicit that it will be removed in a future update.
Windows has no built-in .rdp signature verifier. rdpsign.exe /v is "verbose", not "verify"; in practice the only verifier is Remote Desktop Connection opening the file. Signotaur's verify command will validate the signature and cert chain offline if you want a CI-friendly check.

If you'd rather not think about any of this

The short version: get a code-signing certificate from a public CA that chains to a Windows-preinstalled root, register it with your Signotaur server, sign your .rdp files as part of your distribution workflow, and push the AllowSignedFiles + TrustedCertThumbprints policy out via GPO. After that, signed .rdp files open with no dialog, and the next time Microsoft tightens the rules you've already done the trust-deployment work.

For command-line details and the full signing command reference see the Signotaur documentation. If you run into something specific — especially if you have an internal CA or a less-common PKCS#11 token in play — our support team is happy to help.

Managing Certificate and API Key Expiry with Signotaur

Fri, 13 Mar 2026 03:18:12 GMT

In this article:

Why code signing certificates now expire sooner
How certificate labels remove thumbprints from build scripts
How to rotate and renew API keys safely
How to automate the process in Continua CI

Shorter Certificate Lifetimes Are Coming

Code signing certificates used to last up to three years. As of March 1, 2026, that is no longer the case.

The CA/Browser Forum adopted Ballot CSC-31 on November 17, 2025, reducing the maximum validity period for publicly-trusted code signing certificates from 39 months to 460 days (roughly 15 months). For most teams, that means certificate renewals are now an annual operational task rather than an occasional one.

When a certificate is renewed, it receives a new thumbprint, and build scripts that reference the old thumbprint must be updated. In large CI/CD environments, tracking down every reference can be tedious and error-prone.

Separately, API keys used by CI agents to authenticate with the signing server have their own lifecycle and eventually need to be rotated. Replacing them without interrupting active build pipelines can be challenging.

Signotaur addresses both concerns. Label-based certificate selection decouples build pipelines from individual certificates, while API key rotation with overlap allows credentials to be replaced without downtime. Together they turn what used to be stressful maintenance tasks into routine operations.

Certificate Labels: Automatic Certificate Rotation

The Thumbprint Problem

Traditionally, build scripts reference a code signing certificate by its SHA-1 thumbprint — a 40-character hex string that uniquely identifies the certificate. When you renew, you get a new certificate with a new thumbprint, so every script that signs code needs to be updated. If you sign across multiple CI configurations, that means tracking down and editing each one.

Labels to the Rescue

Signotaur lets you assign a label to each registered certificate — for example, production or nightly. When you request a signing operation by label instead of thumbprint, Signotaur automatically selects the certificate with the latest expiry date among all enabled, non-expired certificates that share that label. This ensures that newly issued certificates automatically take precedence.

The rotation workflow is straightforward:

Register your renewed certificate and assign it the same label as the outgoing one.
Builds automatically pick up the new certificate — no script changes required.
The old certificate expires naturally; remove it from Signotaur when you're ready.

Expiration Monitoring

Signotaur's background monitoring service checks certificate expiration daily and sends email notifications to administrators at configurable intervals. The defaults are 30, 14, 7, 3, and 1 day(s) before expiry, with an additional alert if a certificate has already expired. You can customise these warning thresholds in the server configuration.

During a rotation window — when both the old and new certificates are registered with the same label — the admin UI highlights the duplicate label so you can confirm the overlap is intentional.

API Key Rotation with Overlap

Why Rotate Keys?

API keys grant access to your signing service. If a key is leaked or reused indefinitely, it becomes a long-lived security risk. Regular rotation limits the impact if a key is compromised, satisfies compliance requirements, and handles natural key expiry gracefully. But naive rotation — revoke old, issue new — creates a window where CI agents holding the old key start failing.

How Signotaur Handles It

The rotate-key command creates a new API key while keeping the old one valid for a configurable overlap period of 0–30 days (default: 7 days). During this window, both keys are accepted, allowing CI agents and environments to transition without interruption.

Once the overlap period expires, the old key is automatically revoked. If you prefer to manage revocation manually, pass --no-auto-revoke and the old key will remain valid until you explicitly revoke it.

Safety Guardrails

Role required — users must be assigned the ApiKeyRotator role before they can rotate keys. An administrator can assign this role in the Signotaur admin UI.
Rate limiting — a maximum of 5 rotations per user per 24-hour period prevents accidental key sprawl.
Linear chain only — a key that has already been rotated cannot be rotated again; you must use the successor key. This prevents branching into multiple active key chains.
Proactive expiry checking — the sign command accepts a --fail-if-expiring-within flag (e.g. 14d). If the API key used for signing will expire within that window, the command fails immediately with a clear message — catching the problem in CI before it causes a real signing failure.

Conditional Rotation

The --if-expiring-within flag on rotate-key makes rotation idempotent: the key is only rotated if it expires within the specified duration (e.g. 14d, 1w, 24h). This makes it safe to run rotate-key on every CI build or on a nightly schedule without generating unnecessary keys.

Example scheduled rotation command:

signotaur rotate-key --if-expiring-within 14d

Key Renewal

By default, a rotated key inherits the old key's expiry date. If the old key had 30 days of validity remaining, the new key also expires in 30 days. Over time, repeatedly rotating a key gradually shortens its remaining lifetime — which can be a problem for long-running automation.

The --renew flag gives the new key a fresh validity period starting from the rotation date, rather than inheriting whatever time was left on the old key. Without a value, it uses the server default of 90 days; with a value (e.g. --renew 180d), it sets a specific duration up to a maximum of 365 days.

This pairs naturally with conditional rotation — check whether the key is approaching expiry, and if so, rotate and renew in a single command:

signotaur rotate-key --if-expiring-within 14d --renew

If the renewal duration would be shorter than the old key's remaining validity (for example renewing for 30 days when 60 days remain), the command fails as a safety measure. Pass --allow-validity-reduction to override this check when the shorter duration is intentional.

Putting It Together in Continua CI

Continua CI ships dedicated Signotaur actions for both signing and key rotation, so you can wire up the entire workflow without writing any custom scripts. Before configuring those actions, you'll need to assign a label to your certificates in the Signotaur admin UI.

Assigning a Label to Your Certificates

In the Signotaur admin UI, navigate to Certificates and either add a new certificate or edit an existing one. In the certificate dialog you'll find two name fields:

Alias — a unique display name for the certificate (auto-generated by default, e.g. "CodeSigningCert (2027-12-31)").
Label — an optional identifier used for CLI and CI/CD certificate selection, e.g. production. Multiple certificates can share the same label. Matching is case-insensitive, so Production and production resolve the same way.

When you renew a certificate, register the new one and assign it the same label as the outgoing certificate. The admin UI will show an orange notice confirming that multiple active certificates share the label and that the one with the latest expiry will be selected automatically. No build script changes needed.

For full details, see the Certificates documentation.

Setting Up the Rotate Keys Action

Add the Signotaur Rotate Keys action to a stage — either in a scheduled maintenance configuration or directly in your build configuration. With the If Expiring Within condition the action only rotates the key when expiry is approaching, so it can safely run on every build.

The action is organised into several tabs:

Signotaur Rotate Keys tab — configure Overlap Days (how long the old key remains valid alongside the new one, default 7) and whether to Disable auto-revocation if you prefer to revoke old keys manually.

Server tab — set the Server URL for your Signotaur instance and the API Key Source. Select Value (from variable) and reference a server variable (e.g. %SignotaurAPIKey%) to avoid hard-coding keys in the action.

Conditions tab — set If Expiring Within to make the rotation conditional (e.g. 14d to only rotate if expiry is within two weeks). Enable Ignore already rotated error to safely run the action in concurrent CI builds without failure if the key was already rotated by another build.

Renewal tab — enable the Renew checkbox to give the new key a fresh validity period instead of inheriting the old key's remaining lifetime. Set a specific Renew Duration (e.g. 90d), or leave it blank to use the server default. Check Allow validity reduction if the renewal duration may be shorter than the old key's remaining validity.

Output tab — choose Set Variable as the output destination and select a Server variable to store the new key. This way your sign actions automatically pick up the rotated key without any manual updates.

Full documentation: Signotaur Rotate Keys Action

Setting Up the Sign Action with Label Selection

Add the Signotaur Sign action to your build stage, after compilation and before packaging.

Key fields:

Files to Sign — glob patterns for your build output, e.g. **/*.exe, **/*.dll.
Certificate Selection Mode — set to Label.
Label — your shared label, e.g. production. Signotaur will automatically select the certificate with the latest expiry date.
API Key Source — point to the server variable populated by the Rotate Keys action, or a securely stored key.
Fail If Expiring Within — e.g. 14d. If the API key expires within two weeks, the action fails early so you can rotate before it becomes a blocker.
Timestamp Server & Digest — configure your preferred timestamping authority and hash algorithm.

Full documentation: Signotaur Sign Action

Typical Rotation Workflow

In practice, certificate and API key rotation can be handled with a small amount of scheduled automation in your CI system.

Register renewed certificates in Signotaur and assign them the same label as the previous certificate.
CI builds continue using the label, automatically selecting the certificate with the latest expiry date.
Schedule periodic API key checks using the rotate-key --if-expiring-within option.
The new key is written to a CI server variable, allowing build pipelines to automatically use the rotated key.
Use --renew so rotated keys receive a fresh validity period rather than inheriting the old key's remaining lifetime.
Retire old certificates and keys once they are no longer needed.

Wrapping Up

With code signing certificate lifetimes dropping to roughly 15 months, the days of "set it and forget it" certificate management are over. Signotaur's label-based signing means your CI/CD pipelines don't need to know — or care — which specific certificate is current. And overlap-based API key rotation ensures you can swap credentials without any signing downtime.

These features are already available in Signotaur. If you're evaluating it, check out the Signotaur documentation to get started.

ClickOnce and VSTO Application Signing with Signotaur

Tue, 14 Oct 2025 00:23:40 GMT

If you've been working with ClickOnce or VSTO applications, you know that signing them isn't quite like signing a regular executable. We're pleased to announce that Signotaur now handles ClickOnce and VSTO application signing, taking care of the manifest orchestration so you don't have to.

What Makes ClickOnce and VSTO Different?

When you sign a standard executable or DLL, you're dealing with a single file. The process is straightforward: calculate a hash, sign it, embed the signature. One file, one operation.

ClickOnce and VSTO applications are a different beast entirely. These deployment packages consist of multiple files tied together by manifest files that describe the application structure, dependencies, and deployment configuration. The challenge? Everything needs to be signed in a specific order, and those manifests need to be updated with new hash values after each signing operation.

Here's what's happening under the hood:

Application files get signed first (your assemblies, dependencies, etc.)
The application manifest (.manifest) needs to be updated with the new hash values of those signed files
Then the application manifest itself gets signed
The deployment manifest (.application) needs to be updated with the hash of the signed application manifest
Finally, the deployment manifest gets signed

Miss a step or do things out of order, and Windows will reject your deployment package. It's tedious and error prone to manage manually, which is exactly why we've automated it.

Certificate Requirements

ClickOnce and VSTO signing requires an RSA certificate with specific characteristics:

Algorithm: RSA only (ECC/ECDSA certificates are not supported by the ClickOnce/VSTO signing infrastructure)
Key size: Minimum 2048 bits, though 3072 bits is recommended for better security
Certificate type: Must be a code signing certificate (Authenticode) from a trusted Certificate Authority
Key storage: Since June 2023, CA/B Forum requirements mandate that private keys be stored on secure hardware (USB tokens or HSMs)

Signotaur supports all of these requirements, whether your certificates are stored on YubiKeys, SafeNet tokens, other PKCS#11 HSMs, or in the Windows Certificate Store.

The Publisher Name Challenge

Getting the manifests signed is only half the battle. Making your application display the proper publisher name instead of "Unknown Publisher" during installation is notoriously tricky. Even with a properly signed application, several factors can cause Windows to show "Unknown Publisher":

Certificate chain issues (missing intermediate certificates)
Publisher name in the deployment manifest not matching the certificate's Common Name exactly
Whitespace differences introduced during the signing process
Self-signed or test certificates (which will always show as unknown)
Certificate not from a trusted root CA

When everything is configured correctly, users see a clean installation prompt with your verified publisher information:

When something's wrong — even if the manifests are technically signed — users see the dreaded "Unknown Publisher" warning:

This is why using certificates from trusted CAs and ensuring proper manifest configuration is so important. Signotaur handles all the signing mechanics correctly so all you need to display the verified publisher name is a valid certificate from a publicly trusted Certificate Authority.

Signing Made Simple

To sign a ClickOnce or VSTO application, you only need to point Signotaur at the deployment manifest:

SignotaurTool.exe sign -a  -s  -t  --tr  --td SHA256 path\to\MyApp.application

Signotaur will parse the manifest, identify all the files that are part of the application, sign them in the correct order, and update the hash values throughout the manifest chain. Any files sitting in the deployment folder that aren't referenced in the manifest will be ignored, even if they match your file spec. This keeps things clean and ensures only application files get signed.

Command-Line Parameters

We've added a new --application-name parameter specifically for ClickOnce and VSTO deployments. This value appears in the Windows Start menu when users install your application, giving it a proper identity in the system.

The existing --description and --description-url parameters are used to populate the publisher name and support URL in the deployment manifest. This means if you're already using these parameters for other signing operations, your scripts should work with minimal changes.

What This Means for Your Build Process

If you've been juggling multiple tools or scripts to handle ClickOnce and VSTO signing, you can simplify your build pipeline. Signotaur handles the entire process as a single operation, maintaining the correct signing order and manifest updates automatically. This is particularly useful in CI/CD environments where you need reliable, repeatable signing without manual intervention.

The usual benefits of Signotaur apply here: your certificates stay securely on the server, private keys never travel over the network, and the command-line interface integrates cleanly with your existing build scripts.

For detailed command-line syntax and examples, check out the Signotaur documentation. If you run into any issues or have questions about signing ClickOnce or VSTO applications, our support team is here to help.

Continua CI System Server Properties

Thu, 13 May 2021 12:59:28 GMT

If you are using Continua for your CI, (and if not why not?) ensure that you check out System Server Properties. These allow access to global settings which do not fit on any existing page.

They can be used to configure several aspects of the UI and build process to fit your team preferences. This could simply be the number items to show per page on each of the dashboard views (Server.ProjectsView.*.PageSize), or more complex patterns for detecting errors and warnings in actions settings (Actions.Messages.*Patterns). Some system server properties are rarely needed, but some can be considered essential, such as Server.HostUrl which can be used to ensure the links in notifications go to the correct external host name.

We have recently added some new server properties which allow you to control the tabs on the Queue Options dialog (Server.QueueOptionsDialog.*) and create a banner for displaying a message to all (or a subset of) users (Server.Banner.*).

Here is the result of changing Server.QueueOptionsDialog.TabSequence from "Variables,Repositories,Options"

to "Repositories,Variables,Options".

This is what happens to an existing banner when you change the Server.Banner.MessageType from "Information"

to "Warning".

Server properties can be edited on the "Continua Server - Properties" page located in the "Administration" section of Continua CI. See our documentation for details on all the currently available server properties.

Announcing the Release of Continua CI Version 1.9.2

Mon, 09 Nov 2020 06:16:32 GMT

We are delighted to announce that version 1.9.2 of Continua CI has passed through the beta and release candidate stages, and has now been released. Here is a reminder of the new features in v1.9.2:

Export and Import: You can now export one or more configurations to a file and import them back from the file into Continua CI.
Requeuing Stages: Requeue a failing stage without restarting the build.
Multiple Daily Cleanup Rules: Each type of build by-product can now have a different shelf life.

Export and Import

Users with Configuration Edit permissions can now export one or more project configurations to a YAML or JSON file. This may be for backup, versioning or migration to another server.

The export wizard has a number of steps allowing selection of one or more configurations, and also any related repositories, variables and shared resources.

The configuration details can be exported to YAML or JSON file formats, according to your preferences for readability and differencing.

The resultant file is downloaded to your computer, allowing you to file it away until you need it.

The import wizard also consists of several steps, allowing users with Project Edit permissions to upload a file, ...

choose which items in the file to import and whether to overwrite any existing matching items of create new items.

The import runs in a transaction, so if any modified file content fails validation it will rollback...

allowing you to make changes and retry.

Requeuing Stages

Sometimes a build stage may fail due to external influences. It could be that a file server was offline, network connectivity was down, or a file was locked for access. If it has taken several long stages to get to this point, then having to run the whole build again from the start can be a pain.

The last stage of a completed build can now be requeued, providing that it has failed, stopped or errored, and the server workspace is intact.

If no parts of the server workspace have been removed by the cleanup process, then a Requeue Stage button will be shown after the last stage in the Stages list on the Build page.

This allows you to requeue and execute the stage again!

You can also optionally make changes to the stage actions and requeue the stage with the latest changes.

Multiple Daily Cleanup Rules

Every build that is executed within Continua CI stores information in the server's workspace, such as artifacts and build logs, and entries in the database. These by-products are vital for executing your build process and tracking build information, however, they can also take up considerable disk space over time and have a negative impact on database performance. The cleanup settings define the shelf life for the build by-products.

Up until now, the cleanup settings have been quite limited - you could set up a single policy per configuration defining the build age and build limits for cleaning up either the database, the workspace, or both. Often, however you would want to cleanup the workspace files to save space, well before removing the build from the database. This update allows you to define multiple cleanup rules, with different shelf lives for each type of build by-product.

Each rule can include one or more by-product to clean up.

Download the installers for Continua CI v1.9.2 from the Downloads page

Introducing Continua CI Version 1.9.2 Beta

Sun, 30 Aug 2020 14:12:26 GMT

We are delighted to announce a new beta release of Continua CI. We have added the following new features:

Export and Import: You can now export one or more configurations to a file and import them back from the file into Continua CI.
Requeuing Stages: Requeue a failing stage without restarting the build.
Multiple Daily Cleanup Rules: Each type of build by-product can now have a different shelf life.

Export and Import

Administrators can now export one or more project configurations to a YAML or JSON file. This may be for backup, versioning or migration to another server.

The export wizard has a number of steps allowing selection of one or more configurations, and also any related repositories, variables and shared resources.

The configuration details can be exported to YAML or JSON file formats, according to your preferences for readability and differencing.

The resultant file is downloaded to your computer, allowing you to file it away until you need it.

The import wizard also consists of several steps, allowing you to upload a file, ...

choose which items in the file to import and whether to overwrite any existing matching items of create new items.

The import runs in a transaction, so if any modified file content fails validation it will rollback...

allowing you to make changes and retry.

Requeuing Stages

The last stage of a completed build can now be requeued, providing that it has failed, stopped or errored, and the server workspace is intact.

If no parts of the server workspace have been removed by the cleanup process, then a Requeue Stage button will be shown after the last stage in the Stages list on the Build page.

This allows you to requeue and execute the stage again!

You can also optionally make changes to the stage actions and requeue the stage with the latest changes.

Multiple Daily Cleanup Rules

Each rule can include one or more by-product to clean up.

Download the installers for Continua CI v1.9.2 Beta from the Downloads page

Daily Builds with Continua CI

Sun, 24 May 2020 09:22:55 GMT

Generally, at VSoft, we like to build. So we build every commit and this allows us to look back at our build history and see which changes caused the build to fail. We use manual stage promotion to prevent every build being released until we decide that it is ready to go.

Many teams like to trigger a build at the end of each day, or during the night, compiling the work for the day in one single package.

The obvious choice for this scenario is the Daily Trigger. This can be set to run a build at a specific time every day, or just weekdays - even just weekends for those with alternative lifestyles.

But what if the team is just having a design day, is off on a team building excursion or, perish the thought, a day of meetings! No commits are made, but the daily build still runs even though there are no changes. One possible solution is to use a Discard condition.

This will prevent the build running if there are no changes since the last build.

Another option has been added to Continua CI recently. The Quiet Period setting on Repository Triggers now allows you to enter an End Time rather than an Interval.

Any builds triggered from a repository change are then queued right through the day until the specified end time. Any additional changes added to the configuration repositories during the day are added to the queued build, and when the end time comes up, the build executes on the latest changeset.

If you're going home earlier than the end time and want stuff deployed already, you can swiftly end the quiet period at the click of a button. Using a repository trigger in this way means that you can ignore changes to some files, changesets with a specific comment, or commits from certain users.

- like that hands-on manager who thinks of his commit count as a key performance indicator.

Introducing Continua CI Version 1.9.1 Beta

Wed, 01 May 2019 07:00:08 GMT

This new beta release includes substantial improvements to the expressions engine including new several expressions objects and functions. We have also made some updates to the stage editor, implemented automatic report generation for some reporting actions, and added several new deployment actions providing support for Docker, Azure, SQL packages, File Transfer and SSH.

Continue reading for details of all the new features.

Enhanced expressions engine
Stage editor changes
New premium deployment actions
Other new and updated actions
Automatic reporting

Enhanced expressions engine

The expression engine in Continua CI evaluates expression objects and variables denoted with $ and % characters. It also provides auto-completion suggestions when typing such expressions into expression fields. This has now been overhauled to include function return types, chaining of functions, nesting functions as function parameters, selection and filtering of collections and many improvements to expression parsing. We have added several new functions, objects and collections to give access to more values and allow you to manipulate those values.

You can now, for example, use the following expression to get the time that the penultimate build stage finished;

 $Build.Stages.Item($Build.Stages.Count.Decrement()$).Finished.ToLongTimeString()$

combine the result of multiple flags by chaining functions, as in this expression;

$Build.HasErroredStages.Or($Build.HasFailedStages$).Or($Build.HasWarnings$)$

or use the following expression to get the comment of the first build changeset in the build containing the word 'merge' (ignoring case):

$Source.SuperFancyRepo.Changesets.First(Comment, Contains, "merge", true).Comment$

We have also included functions to get the value of a variable as a type, allowing you to use properties or functions on the variable value.

You can, for example, now use the following expression to get the abbreviated day of the week from a variable entered using a DateTime prompt;

$Utils.GetDateTime(%DateTimeTest%).DayOfWeek.Substring(0, 3)$

use expressions to do some more complex maths on a Numeric variable;

  $Utils.GetNumber(%NumberTest%).Floor().Modulus(10).Multiply(100)$

or get the first selected value in a checkbox select variable with this expression:

$Utils.GetString(%CheckboxSelectTest%).SplitWithQuotes(",").First()$

You can see a full list of available expression objects, collection and functions on the Expression Objects page of the documentation.

Auto-completion has also been revamped so show more information in the suggestions list. A list of parameters with types is now shown for each for each function. Descriptions are also displayed on mouse over for each object, collection and function in the suggestions list. We have also removed some annoying quirks with expression auto-completion where the cursor would end up in the wrong place or end characters would be added in the wrong place.

Stage editor changes

As Continua CI matures, the number of actions (and categories) has increased. This can make it more difficult to find the action you need. We have therefore redesigned the action list.

The list of categories has been pulled up into a drop down menu with all actions listed below by default.

The filtering of actions using the search box is now fuzzier, using partial and keyword matches.

Stage buttons now resize (up to a maximum) to fit the stage name. If you stage names are short, this means you can fit more stages into your browser width. If your stage names are long, then the text will no longer escape the stage borders. Really long stage names which do not fit the maximum stage button size will now be truncated.

All actions now include a Validate button to allow you to check that all fields have valid values before saving.

New premium deployment actions

We have added a set of premium actions which can be used for deploying the results of your build. The following actions can only be used if you have purchased one or more concurrent build licenses.

File Transfer action: This allows you to upload files to a remote server via FTP, FTPS and SFTP.

SSH Run Script action: This can be used to run a script or list of commands on an SSH server.

Azure actions: Several new actions are available to allow you to deploy web apps, function apps, files and blobs to Azure.

Create Azure Resource Group
Delete Azure Resource Group

Create Azure App Service Plan
Delete Azure App Service Plan

Create Azure Web App
Deploy Azure Web App
Upload Azure Web App
Control Azure Web App
Delete Azure Web App

Create Azure Function
Deploy Azure Function
Delete Azure Function

Create Azure Storage Account
Get Azure Storage Account Keys
Delete Azure Storage Account

Create Azure Storage Container
Delete Azure Storage Container

Upload Azure Blob
Delete Azure Blob

Create Azure File Share
Delete Azure File Share

Create Azure Directory
Delete Azure Directory

Upload Azure File
Delete Azure File

Docker actions: These new actions are available to allow you to build, deploy and manage Docker containers.

Docker Build
Docker Command
Docker Commit
Docker Inspect
Docker Pull
Docker Push
Docker Run
Docker Stop
Docker Tag

SQL Package actions: These new actions allow you to create, update and export SQL Server database schemas and table data.

SQL Package Export
SQL Package Extract
SQL Package Import
SQL Package Publish
SQL Package Script

Other new and updated actions

Extent Reports: Wrapper for the Extent Reports CLI for reporting on NUnit results.

ReportGenerator: Updated to include all the latest command line options.

Rename Directory: Does what it says on the tin..

Automatic reporting

Currently, there are a few steps to configure when setting up a report. You have to ensure that the report files are included in the Workspace Rules and that the report is defined in the Reports section of the configuration wizard. Furthermore, it's also recommended to include the report files in the artifact rules so that you can control when they are cleaned up.

To simplify this process, we have added a new option to automatically register the report with the server to actions which generate reports (FinalBuilder, ReportGenerator and the new Extent Reports action). Ticking this option shows a new tab where you can enter the name, description and run order of the report. When a stage completes, any report files generated by actions where this option is turned on, will automatically be copied to the server workspace. The main report file will be registered as a report and all report files will be registered as artifacts.

Download the installers for Continua CI v1.9.1 Beta from the Downloads page

Introducing Continua CI Version 1.9

Tue, 14 Aug 2018 13:47:08 GMT

Version 1.9 is now out of beta and available as a stable release. Thank you to those of you who have already tried out the beta - especially those who reported issues.

This version brings major changes to the notifications system. We redesigned it using a common architecture, that makes it much easier to add new notification publisher types. Where previously, only email, XMPP and private message notifications were available, there are now publishers for Slack, Teams, Hipchat and Stride. And we can now add more (let us know what you need).

We are no longer limited to one publisher of each type. You may, for example, have different email servers for different teams on your company. You can set up two email publishers, one for each server, and set up subscriptions so that notifications from different projects go to different email servers. Likewise for different Slack workspaces, Teams channel connectors and so on.

We have also improved the XMPP publisher to support sending notifications to rooms. Subscriptions have been improved, allowing you to specify a room and/or channel for this and other publishers.

User preferences have been updated allowing each user to specify a recipient id, username or channel per publisher.

You can see some metrics on the throughput of each publisher (number of messages on queue, messages sent per second, average send time, etc.) on the Publishers page in the Administration area. This also shows real-time counts of any errors occurring while sending messages and also any messages waiting on a retry queue due to rate limiting or service outages. This allows you to know when you need to upgrade rate limits or make other service changes.

The Templates page has been updated. Templates are now divided into a tab per publisher. The list of available variables for each event type has been moved to a expandable side panel.

This release is built on .Net Framework version 4.7.2, which has allowed us to upgrade a number of third party libraries, including the database ORM and PostgreSQL drivers. This has noticeably improved performance, as well as providing us with a richer platform to build future features on. The setup wizard will prompt for you to install .Net Framework version 4.7.2, before continuing with the installation.

Note that applications running on .Net 4.7.2 do not run on versions of Windows prior to Windows Server 2008R2 and Windows 7 SP1. We are also dropping the 32-bit server installer. This is mainly to reduce testing overheads. We will still be releasing 32-bit agents for those who are using 16-bit compilers.

We will continue to provide bug fixes to Continua CI version 1.8.1 for while to give you time to migrate from older platforms.

Introducing archive rules in Continua CI

Wed, 16 May 2018 14:15:12 GMT

In version 1.8.1.870 of Continua CI, we have added new archiving functionality to the workspace and repository rules.

Builds can generate a lot of output files: binary library files or report files, for example. Copying a large number of these files back to the server at the end of the build can take time. Manually downloading each individual artefact from the server can be a tedious task, so compressing these files into a handy bundle makes sense.

Previously, you would have needed to use actions, such as the Seven Zip action, in your build stages to zip these files. The compression can now be performed as part of the agent-to-server workspace rules.

To compress a set of files in the agent workspace to an archive in the server workspace, specify a file with a zip extension on the left-hand side of a agent-to-server workspace rule.

e.g.



    Libraries.zip < Output/**.dll

Note that the all the usual operators are taken into account when compressing files so, in the above example, the directory structure is preserved. Likewise, using the <- operator will cause all matching files to be flattened into the root folder of the zip file.

Doubling up with the << operator will delete any existing zip file before compressing to a new file. Without the << operator, multiple sets of files can be added to the same archive file.

e.g.



    Reports.zip < Output/**.html
	Reports.zip < Output/**.css

You can also compress files into subfolders within the zip file using the new : operator

e.g.



    Reports.zip:/css < Output/**.css

Once files have been compressed at the end of one stage, you may need to access the contents of zip files in the next stage. Additionally, you may wish to unpack a zip file from your repository at the start of a stage. The : operator facilitates the extracting of zip files in server-to-agent workspace rules and repository rules.

To extract a set of files from an archive in the server workspace to a folder in the agent workspace, specify a file with a zip extension on the left-hand side of a server-to-agent workspace rule. Ensure that you follow the ‘zip’ with a : operator, otherwise the zip file will just be copied.

e.g.



    Libraries.zip: > Libraries

This also works for repository rules.

e.g.



	$Source.MyRepo$/Documents.zip: > Docs/Main

Note that the all the usual operators >, >>, -> and --> have the same meaning when extracting files as they have when copying file; signifying whether to preserve the directory structure within the zip file and whether to empty the destination folder.

You can also specify a pattern after the : operator, allowing you to filter the extracted files.

e.g.



	Libraries.zip:/plugins/**.dll > Libraries/Plugins
	$Source.MyRepo$/Documents.zip:**.md > Docs/Markdown

See the Workspace Rules documentation for further details on the new archive rules syntax.

Introducing Continua CI Version 1.8.1

Thu, 08 Sep 2016 16:43:33 GMT

This version adds several back-end performance enhancements including significant improvements to database query caching. We have also updated various third party packages and upgraded the bundled PostgreSQl database from version 9.3.4 to version 9.5.3. What’s more, this release builds upon all the improvements and fixes made to version 1.8.

New Actions

To keep up with the latest developments in Visual Studio, we have added several new actions for working with .Net Core projects. The DotNet Build, DotNet Pack, DotNet Publish, DotNet Restore, DotNet Run and DotNet Test actions all run the DotNet Cli command line.

This release also includes a new action for importing XUnit tests from an XML report file. The sort of file you may choose to output from the DotNet Test action.

To polish this off we have added new NPM Pack and NPM Publish actions for sharing your completed packages.

New Build Event Handlers

A powerful new addition to the Continua CI build event handlers is the HTTP Request handler which allows you to send JSON or XML to HTTP endpoints via GET, POST. PUT, DELETE, PATCH methods and extract values from the results to set as Continua CI variables.

This enables interaction with a various existing web services and REST APIs. You could, for example, use this feature to send a message via Slack when a build starts, tag a commit on GitLab when a build finishes or even translate a variable value to Azerbaijani using Google Translate API. If you have any in-house web services which handle HTTP requests, it is likely that these can be accessed too.

We have also added a new GitHub Release build event handler for creating, updating and deleting GitHub releases. This also allows you to upload artifacts as GitHub release assets.

Other New Features

Build Event Handler conditions. You can now control the triggering of handlers based on the value of build variables or expression objects. These values may be specified when queuing a manual build or set in the stage workflow. You could, for example, only send a GitHub Release if the number of failed unit tests $Build.Metrics.UnitTests.Failed$ is zero.

Continue on failure. Builds can now be set to progress to the next stage after one stage has failed. Stage gates now include an $Stage.IsSuccessful$ condition by default. This can be removed to allow the build to continue to the next stage when a stage fails. So you can see what failed, the stages are now coloured green or red in Tile and Details dashboard views to indicate an success or failure status.

New cleanup options. We have also made some changes to the server cleanup policy, giving you the options to clean up build statistics. The database category has also been split up so that build unit tests can be cleaned up without cleaning up the full build. This is important to prevent database tables growing too large when you have a large number of unit tests.

Continua CI 1.8 Released

Thu, 14 Apr 2016 13:07:29 GMT

We are pleased to announce that Continua CI 1.8 has been released. It was actually released a couple of days ago, but for anyone who missed it, here is a heads up with and overview of the new features. We'd also like to thank all those who downloaded the beta - the time and effort spent reporting issues helped us to fix some important bugs and is most appreciated.

Version 1.8 adds the following features which build upon all the improvements and fixes made to version 1.7.1.

Dashboard Filtering

We've added a new filter box to the dashboard so you can quickly find the configuration (or project) that you are looking for as you type. Use the shortcut key F on the dashboard pages to focus on the filter box and start typing.

Shared Resources

Many of you have requested more control over the number of builds which can run concurrently for some configurations. This may be to restrict the number of times a particular tool is run due to a license, memory or processor limit, or to prevent concurrency issues with multiple build stages simultaneously writing to the same file, folder or network resource.
You can now allocate quotas to named Shared Resources and specify that builds and stages must acquire a lock on the Shared Resource before running. If all locks are allocated, then the build or stage will wait on the queue until a lock is released.

Shared resources can be associated with the server or a particular agent in the Administration pages.

Agent shared resources are acquired when selecting an agent to run a stage. Continua will select the agent with the largest available quota of each shared resource.

Server shared resources can also be acquired when selecting an agent, or while on the build queue after evaluating configuration conditions.

We hope you find that shared resources can provide many different ways to control the build process.

Requeue Build

Sometimes a build may fail due to an offline network resource, or some logical error in the stage workflow. Up until now, your only option was to re-run a build for the same branch heads. If any new changesets had been committed to the branch since that build, then you are out of luck.

The new Requeue Build button on the Build View page allows you to requeue an existing build using the same changesets, variables and queue options. Any changes to the configuration such as stage actions or repositories are taken into account and used for the new build.

You can also change the priority, comment and variables before requeuing the build.

Clicking on the “Build requeue options” menu item will open the Queue Options dialog.

Persist Build Variables

Another common request has been to persist variable values from one build to another build. This may be to keep a count of builds on a particular branch or to flag that some actions have been completed in one build and do not need to be repeated.

Continua CI takes a copy of configuration and project variables at the start of each build. These copies are referred to as build variables. Any changes to build variables are normally discarded when the build finishes and cannot be used by other builds.

The new Persist Build Variable build event handler allows you to save the value of the build variables when specific events happen in the build timeline. This is stored as the value of the configuration variable. Subsequent builds will then pick up this revised value and use it as the initial value of the build variable.

As Continua CI allows multiple builds to run concurrently, it is important to control when the variables are overwritten. A later build may run faster and finish before a build which started earlier, causing unexpected results. You can optionally state that a variable should not be persisted if the configuration variable has been modified (e.g. by another build) since a specified build event, such the build start.

You can also prevent concurrency issues by using this feature in conjunction with shared resource locks.

Other New Features

You can now set the Variables display order of variable prompts on the Queue Options dialog.
We have provided buttons for cloning Triggers, Repositories and Build Event Handlers.
Configuration Conditions can now be disabled.
All actions which run external processes now have a Timeout (in seconds) setting.
We have also added a new Cake build runner action and a new VSTest unit testing action.

Introducing Continua CI Version 1.8 Beta

Tue, 08 Mar 2016 10:10:00 GMT

This version adds several new features which build upon all the improvements and fixes made to version 1.7.1.

Dashboard Filtering

Shared Resources

Shared resources can be associated with the server or a particular agent in the Administration pages.

Agent shared resources are acquired when selecting an agent to run a stage. Continua will select the agent with the largest available quota of each shared resource.

Server shared resources can also be acquired when selecting an agent, or while on the build queue after evaluating configuration conditions.

We hope you find that shared resources can provide many different ways to control the build process.

Requeue Build

You can also change the priority, comment and variables before requeuing the build.

Clicking on the “Build requeue options” menu item will open the Queue Options dialog.

Persist Build Variables

You can also prevent concurrency issues by using this feature in conjunction with shared resource locks.

Other New Features

You can now set the Variables display order of variable prompts on the Queue Options dialog.
We have provided buttons for cloning Triggers, Repositories and Build Event Handlers.
Configuration Conditions can now be disabled.
We have also added a new Cake build runner action

Continua CI Version 1.7 released

Sun, 23 Aug 2015 16:20:37 GMT

Version 1.7 of Continua is now released. A big thank you to all those who downloaded the beta and especially those of you who reported issues and bugs.

This version introduces several new features, many of which have been requested by users over the past few months. These features are built upon the various improvements and bug fixes applied in revisions to version 1.6. Please don’t dismay if your requested feature is not included yet, it is still high on our to-do list. Indeed we have several other features specced out, and some partially developed in the background.

Version 1.7 Features

New Builds View dashboard

This view is useful for project administrators and shows a list of active builds across all viewable configurations. This includes running builds, queued builds and builds awaiting promotion.

New panel of indicators

Some important numbers including the total count of queued and running builds, as well as available agents and concurrent build licenses.

New Repositories tab

This is accessed via the Configurations view and shows status of each repository. We've also included “Check Now” buttons for immediately polling each repository. You can also initiate repository checking from all existing repository pages

Project-wide and configuration versioning options.

We've added some new options in the details section of the project and configuration wizards

Project-wide versioning: The build version number can now be incremented across many configurations within a project.
Build number re-use: A new option at the project or configuration level to decrement the version counter when a build is discarded while initialising. e.g. due to configuration conditions. Please note that the build number will be decremented only if no other build has started in the mean time and is using a later build number.

Improvements to Build Completed triggers.

Variable expressions: You can now use expressions when defining variables allowing you to pass information from triggering to triggered build.
New conditions tab: This allows you to use expressions to control whether a build is triggered

Improvements to Repository triggers.

Trigger on specific file change types: Triggers can now be set to start only when the changeset contains certain types of file changes e.g. additions, modifications and deletions.
Trigger file pattern: You can now specify a file pattern for repository triggers to restrict triggering only to changesets containing matching files.
Trigger comment pattern: You can also limit triggering to changesets with specific text in the comment.

Other build features

New force repository check option in queue build dialog allowing control over whether to recheck repository when building. There is also a default setting for each configuration
Improvements to Stop Build buttons on dashboard view to ensure that the build stopped is always the latest build at the time when the button was clicked. Stop build dialogs also now display the build number of the build being stopped.

Actions and event handlers

New node.js actions
- Package management with Npm and Bower
- Grunt and Gulp build runners
- Unit testing with Mocha
New build event handler for posting status updates to a Stash server
Log Entry action now allows you to add the message as a build comment. This can be useful for showing additional build details on the build view page.
New comments field on all actions – displayed as a tooltip in Stages editor.

New ContinuaCI.* system environment variables are now available to all executable actions.

ContinuaCI.AgentProperty.*

                ContinuaCI.Variable.*

                ContinuaCI.Project.Name

                ContinuaCI.Configuration.Name

                ContinuaCI.Build.Id

                ContinuaCI.Build.BuildNumber

                ContinuaCI.Build.ChangesetCount

                ContinuaCI.Build.ChangesetRevisions

                ContinuaCI.Build.ChangesetTagNames 

                ContinuaCI.Build.ChangesetUserNames 

                ContinuaCI.Build.Elapsed 

                ContinuaCI.Build.HasNewChanges

                ContinuaCI.Build.IsFeatureBranchBuild

                ContinuaCI.Build.IssueCount

                ContinuaCI.Build.LatestChangeset.Created

                ContinuaCI.Build.LatestChangeset.IssueCount

                ContinuaCI.Build.LatestChangeset.RepositoryName

                ContinuaCI.Build.LatestChangeset.Revision

                ContinuaCI.Build.LatestChangeset.TagCount

                ContinuaCI.Build.LatestChangeset.UserName

                ContinuaCI.Build.Started

                ContinuaCI.Build.StartedBy

                ContinuaCI.Build.TimeOnQueue

                ContinuaCI.Build.UsesDefaultBranch

                ContinuaCI.Build.Version

Execute Program, DOS Command and PowerShell actions now include an option to generate a context XML file. This file contains details of the build including repositories, changesets and files for you to parse with your own script or program.

Git repositories

Case-only renames are now recorded in the repository cache.
New option to list author instead of committer as changeset username

Version 1.7 is ready for you to download and install. All feedback is welcome!

Introducing Continua CI Version 1.7 beta

Wed, 29 Jul 2015 15:30:43 GMT

Version 1.7 Features

New Builds View dashboard

This view is useful for project administrators and shows a list of active builds across all viewable configurations. This includes running builds, queued builds and builds awaiting promotion.

New panel of indicators

Some important numbers including the total count of queued and running builds, as well as available agents and concurrent build licenses.

New Repositories tab

Project-wide and configuration versioning options.

We've added some new options in the details section of the project and configuration wizards

Project-wide versioning: The build version number can now be incremented across many configurations within a project.
Build number re-use: A new option at the project or configuration level to decrement the version counter when a build is discarded while initialising. e.g. due to configuration conditions. Please note that the build number will be decremented only if no other build has started in the mean time and is using a later build number.

Improvements to Build Completed triggers.

Variable expressions: You can now use expressions when defining variables allowing you to pass information from triggering to triggered build.
New conditions tab: This allows you to use expressions to control whether a build is triggered

Improvements to Repository triggers.

Trigger on specific file change types: Triggers can now be set to start only when the changeset contains certain types of file changes e.g. additions, modifications and deletions.
Trigger file pattern: You can now specify a file pattern for repository triggers to restrict triggering only to changesets containing matching files.
Trigger comment pattern: You can also limit triggering to changesets with specific text in the comment.

Other build features

New force repository check option in queue build dialog allowing control over whether to recheck repository when building. There is also a default setting for each configuration
Improvements to Stop Build buttons on dashboard view to ensure that the build stopped is always the latest build at the time when the button was clicked. Stop build dialogs also now display the build number of the build being stopped.

Actions and event handlers

New node.js actions
- Package management with Npm and Bower
- Grunt and Gulp build runners
- Unit testing with Mocha
New build event handler for posting status updates to a Stash server
Log Entry action now allows you to add the message as a build comment. This can be useful for showing additional build details on the build view page.
New comments field on all actions – displayed as a tooltip in Stages editor.

New ContinuaCI.* system environment variables are now available to all executable actions.

ContinuaCI.AgentProperty.*

                ContinuaCI.Variable.*

                ContinuaCI.Project.Name

                ContinuaCI.Configuration.Name

                ContinuaCI.Build.Id

                ContinuaCI.Build.BuildNumber

                ContinuaCI.Build.ChangesetCount

                ContinuaCI.Build.ChangesetRevisions

                ContinuaCI.Build.ChangesetTagNames 

                ContinuaCI.Build.ChangesetUserNames 

                ContinuaCI.Build.Elapsed 

                ContinuaCI.Build.HasNewChanges

                ContinuaCI.Build.IsFeatureBranchBuild

                ContinuaCI.Build.IssueCount

                ContinuaCI.Build.LatestChangeset.Created

                ContinuaCI.Build.LatestChangeset.IssueCount

                ContinuaCI.Build.LatestChangeset.RepositoryName

                ContinuaCI.Build.LatestChangeset.Revision

                ContinuaCI.Build.LatestChangeset.TagCount

                ContinuaCI.Build.LatestChangeset.UserName

                ContinuaCI.Build.Started

                ContinuaCI.Build.StartedBy

                ContinuaCI.Build.TimeOnQueue

                ContinuaCI.Build.UsesDefaultBranch

                ContinuaCI.Build.Version

Execute Program, DOS Command and PowerShell actions now include an option to generate a context XML file. This file contains details of the build including repositories, changesets and files for you to parse with your own script or program.

Git repositories

Case-only renames are now recorded in the repository cache.
New option to list author instead of committer as changeset username

Version 1.7 beta is ready for you to download and install. All feedback is welcome!

Deployment with Continua CI 1.5 and Octopus Deploy

Wed, 02 Jul 2014 16:12:00 GMT

So you've got your Continua CI server set up to automatically build, run unit tests and produce reports for your awesome new web application. Now you're ready to try out your project in its natural environment and then eventually release it to the wild for well-deserved public applause.

Up until now, your options were either to use a Copy action to push the files up to test server and a PowerShell action to set up web services, or preferably run a FinalBuilder script utilising the plethora of actions available for transferring files and interacting with web servers.

As of version 1.5, Continua CI can also work together with Octopus Deploy server to provide an end-to-end continuous delivery mechanism. Using the new build event handlers feature, Continua CI builds can now be set up to create Octopus Deploy releases and initiate deployment to test and production environments, at key points in the build process.

This post will walk through the steps required to push a .Net web application built in Continua to Octopus Deploy and trigger a deployment process to effortlessly get your application running on your test and production servers.

Preparing your solution

Octopus Deploy requires that you provide your applications as NuGet packages. You can create and push the package to the Octopus Deploy server using Nuget Pack and Push actions, or create and push an OctoPack from MSBuild or VisualStudio build runner actions.

Lets go with the recommended OctoPack option. First prepare your Visual Studio solution - use the NuGet package manager to install the OctoPack package into the projects you want to deploy. This will include web application projects, console application projects and Windows service projects but not class libraries and unit test projects.

You can now optionally add a .nuspec file to the root folder of your project to describe the contents of your package. If you don't provide a .nuspec file, OctoPack will automatically create one based on your project settings.

Setting up the deployment process

Next head over to your Octopus server and set up a deployment project. This should include a “Deploy a NuGet package” process step as below.

We will set this to retrieve the application package from the built-in NuGet feed. Note that the NuGet package id should match the id element in your .nuspec file - this will default to the name of your assembly.

We added a few more steps:

And some variables:

Setting up the build process

You can now get back to Continua and set up a configuration for building your project. Once you have entered the configuration details and linked up the repository containing your project, move on over to the Stages page:

For this simple example you'll need two actions: a NuGet Restore action to ensure that the OctoPack package is available for the build and an MSBuild action to build and push the application to your Octopus Deploy server.
Just enter the path to your solution for the NuGet Restore action (the other fields can be left as is) and complete the main tab of the MSBuild action as required for your project.

You then need to enter some additional properties to tell MSBuild to run OctoPack and tell it where to send your package.

Set the RunOctoPack property to true and the OctoPackPublishPackageToHttp property to the URL for the NuGet feed on the Octopus Deploy server e.g. https://octopusserver/nuget/packages

You will also need to provide an OctoPackPublishAPIKey property – you can generate an API key on your profile page on the Octopus Deploy server.

Optionally, you can use the OctoPackPackageVersion to specify up the package version. Here we use Continua expressions to set this based on the build version. If you leave this out then OctoPack will get this value from the AssemblyVersion property in your AssemblyInfo.cs file.

Once the actions are set up and saved, run a build and check that your package gets uploaded to the Octopus Deploy server. Then create a release for your deployment project and test that it deploys ok. Now we are ready to look into how to run this process automatically from Continua CI.

Build event handler

On the Continua CI configuration wizard after Stages, we have a new area titled Events. Here you can add Build Event Handlers for tagging repository changesets, updating the GitHub status and interacting with Octopus Deploy.

Create a new build event handler, give it a name and select the Octopus Deploy as the Type.

You can now provide general project details under the Octopus Deploy tab.

The Octopus Deploy URL should end with '/api' e.g. https://octopusserver/api. Enter the API key generated under your Octopus Deploy profile and the name of your deployment project.

You can then choose one or more actions to run. The available options are Create, Deploy and Promote and are used to create a new deployment release, deploy a release to an environment and promote a release from one environment to another. As you select each action, new tabs open so you can provide further details and hook the action to a build event.

Creating a release

Before you can deploy an application you need to create a Octopus Deploy release

When creating a release you can specify the Release Version or leave this blank to automatically create a number based on the highest package version. You must provide either a Default Package Version or Step Package Versions for each step which requires one e.g.

Flip over to the Create Options tab to tell Continua when to create the release.

There are six Build Events available to choose from. Some allow you to select a Stage and some allow you to select a successful or failed Build Status

On Before Stage Start
On Sending Stage To Agent
On Stage Completed
On Build Pending Promotion
On After Build Continued
On Build Completed

Generally we want to create the release at the start of the build before the first stage starts.

Deploying to an environment

Now on to the crux of this whole process - deploying your application. We generally deploy to a Test environment first and then, once we are happy with the outcome, promote to a User Acceptance environment or directly to Production. Continua CI allows you to deploy a release previously created by a Create action in the same build event handler, the highest release version in the project or a specific release version. It's up to you to ensure that the release version exists before the deploy action is run. An environment can consist of multiple machines - you can specify which machines you want to deploy to. If no machines are specified then the release will be deployed to all machines in the environment.

When selecting the Build Event for deployment, ensure that it is triggerred after the package has been built and pushed to the Octopus Deploy server. Here we have set this to be run once the Build stage has completed successfully.

Promoting a release

You can promote the latest release from one environment to another. Ideally this would be linked to the promotion of a stage e.g. a testing stage, so that the application can be promoted from a test environment to production environment.

We have set our test stage to require manual promotion;

and set our promote action to run when a build is continued after waiting for promotion.

Variables

You can also pass variables from Continua CI to your deployment, these will be sent to the Octopus Deploy server before each action is run, updating the variables for the deployment project. We have used expressions is this example to send the build versions number and branch name. These variables can then be used to update project files with details for display or configure services differently depending on the source of the project.

Running the configuration

Once your build event handler dialog has been completed and saved, its time to start running the configuration. As the build processes Continua CI will display status information mirroring the process running on Octopus Deploy.

You can also see full details of the deployment process in the build log.

And all going well you will now see a successful deployment on your Octopus Deploy server!

VSoft Technologies Blogs

Signotaur 2.1: signing documents, not just code

PAdES, XAdES and CAdES

Choosing a signature level

Signing a document

Verifying document signatures

Document-signing certificates

Certificate trust

Using document signing in a pipeline

Also in Signotaur 2.1

Summary

Signotaur 2.0: managing certificates, not just signing with them

PAdES, XAdES and CAdES

Choosing a signature level

Signing a document

Verifying document signatures

Document-signing certificates

Certificate trust

Using document signing in a pipeline

Also in Signotaur 2.1

Summary

Signing files that can't carry a signature: detached CMS for ZIPs, ISOs and more

Archives and disk images: nothing to do

Other file types: --detached

Choosing where the signature lands

Verifying

Wrapping up

Signing .rdp files with Signotaur (and surviving the April Windows update)

What Microsoft changed

Why people got caught out

The actual recipe (no dialog at all)

What Signotaur does when you sign a .rdp file

An example

Deploying the policy to the fleet

What you still can't do

If you'd rather not think about any of this

Managing Certificate and API Key Expiry with Signotaur

Shorter Certificate Lifetimes Are Coming

Certificate Labels: Automatic Certificate Rotation

The Thumbprint Problem

Labels to the Rescue

Expiration Monitoring

API Key Rotation with Overlap

Why Rotate Keys?

How Signotaur Handles It

Safety Guardrails

Conditional Rotation

Key Renewal

Putting It Together in Continua CI

Assigning a Label to Your Certificates

Setting Up the Rotate Keys Action

Setting Up the Sign Action with Label Selection

Typical Rotation Workflow

Wrapping Up

ClickOnce and VSTO Application Signing with Signotaur

What Makes ClickOnce and VSTO Different?

Certificate Requirements

The Publisher Name Challenge

Signing Made Simple

Command-Line Parameters

What This Means for Your Build Process

Continua CI System Server Properties

Announcing the Release of Continua CI Version 1.9.2

Introducing Continua CI Version 1.9.2 Beta

Daily Builds with Continua CI

Introducing Continua CI Version 1.9.1 Beta

Introducing Continua CI Version 1.9

Introducing archive rules in Continua CI

Introducing Continua CI Version 1.8.1

New Actions

New Build Event Handlers

Other New Features

Continua CI 1.8 Released

Dashboard Filtering

Shared Resources

Requeue Build

Persist Build Variables

Other New Features

Introducing Continua CI Version 1.8 Beta

Dashboard Filtering

Other file types: `--detached`