{
	"id": "836f1da7-6a4c-45f4-a881-0a375c6fd565",
	"created_at": "2026-04-06T00:19:23.851267Z",
	"updated_at": "2026-04-10T03:22:06.855512Z",
	"deleted_at": null,
	"sha1_hash": "df47235a873681ff000eed5a48e45fa1f5abd8d8",
	"title": "ClickOnce and Authenticode - Visual Studio (Windows)",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 51355,
	"plain_text": "ClickOnce and Authenticode - Visual Studio (Windows)\r\nBy Mikejo5000\r\nArchived: 2026-04-05 18:45:51 UTC\r\nAuthenticode is a Microsoft technology that uses industry-standard cryptography to sign application code with\r\ndigital certificates that verify the authenticity of the application's publisher. By using Authenticode for application\r\ndeployment, ClickOnce reduces the risk of a Trojan horse. A Trojan horse is a virus or other harmful program that\r\na malicious third party misrepresents as a legitimate program coming from an established, trustworthy source.\r\nSigning ClickOnce deployments with a digital certificate is an optional step to verify that the assemblies and files\r\nare not tampered.\r\nThe following sections describe the different types of digital certificates used in Authenticode, how certificates are\r\nvalidated using Certificate Authorities (CAs), the role of time-stamping in certificates, and the methods of storage\r\navailable for certificates.\r\nAuthenticode and code signing\r\nA digital certificate is a file that contains a cryptographic public/private key pair, along with metadata describing\r\nthe publisher to whom the certificate was issued and the agency that issued the certificate.\r\nThere are various types of Authenticode certificates. Each one is configured for different types of signing. For\r\nClickOnce applications, you must have an Authenticode certificate that is valid for code signing. If you attempt to\r\nsign a ClickOnce application with another type of certificate, such as a digital e-mail certificate, it will not work.\r\nFor more information, see Introduction to code signing.\r\nYou can obtain a certificate for code signing in one of three ways:\r\nPurchase one from a certificate vendor.\r\nReceive one from a group in your organization responsible for creating digital certificates.\r\nGenerate your own certificate by using the New-SelfSignedCertificate PowerShell cmdlet, or by using\r\nMakeCert.exe, which is included with the Windows Software Development Kit (SDK).\r\nA certificate generated using New-SelfSignedCertificate or the MakeCert.exe utility is commonly called a self-cert\r\nor a test cert. This kind of certificate works much the same way that a .snk file works in the .NET Framework. It\r\nconsists solely of a public/private cryptographic key pair, and contains no verifiable information about the\r\npublisher. You can use self-certs to deploy ClickOnce applications with high trust on an intranet. However, when\r\nthese applications run on a client computer, ClickOnce will identify them as coming from an Unknown Publisher.\r\nBy default, ClickOnce applications signed with self-certs and deployed over the Internet cannot utilize Trusted\r\nApplication Deployment.\r\nhttps://learn.microsoft.com/en-us/visualstudio/deployment/clickonce-and-authenticode?view=vs-2022\r\nPage 1 of 3\n\nBy contrast, if you receive a certificate from a CA, such as a certificate vendor, or a department within your\r\nenterprise, the certificate offers more security for your users. It not only identifies the publisher of the signed\r\nsoftware, but it verifies that identity by checking with the CA that signed it. If the CA is not the root authority,\r\nAuthenticode will also \"chain\" back to the root authority to verify that the CA is authorized to issue certificates.\r\nFor greater security, you should use a certificate issued by a CA whenever possible.\r\nFor more information about generating self-certs, see New-SelfSignedCertificate or MakeCert.\r\nTimestamps\r\nThe certificates used to sign ClickOnce applications expire after a certain length of time, typically twelve months.\r\nIn order to remove the need to constantly re-sign applications with new certificates, ClickOnce supports\r\ntimestamp. When an application is signed with a timestamp, its certificate will continue to be accepted even after\r\nexpiration, provided the timestamp is valid. This allows ClickOnce applications with expired certificates, but valid\r\ntimestamps, to download and run. It also allows installed applications with expired certificates to continue to\r\ndownload and install updates.\r\nTo include a timestamp in an application server, a timestamp server must be available. For information about how\r\nto select a timestamp server, see How to: Sign Application and Deployment Manifests.\r\nUpdate expired certificates\r\nIn earlier versions of the .NET Framework, updating an application whose certificate had expired could cause that\r\napplication to stop functioning. To resolve this problem, use one of the following methods:\r\nUpdate the .NET Framework version 3.5 or later.\r\nUninstall the application, and reinstall a new version with a valid certificate.\r\nStore certificates\r\nYou can store certificates as a .pfx file on your file system, or you can store them inside of a key container.\r\nA user on a Windows domain can have a number of key containers. By default, MakeCert.exe will store\r\ncertificates in your personal key container, unless you specify that it should save it to a .pfx instead.\r\nMage.exe and MageUI.exe, the Windows SDK tools for creating ClickOnce deployments, enable you to\r\nuse certificates stored in either fashion.\r\nRelated content\r\nClickOnce security and deployment\r\nSecure ClickOnce applications\r\nTrusted application deployment overview\r\nMage.exe (Manifest Generation and Editing Tool)\r\nhttps://learn.microsoft.com/en-us/visualstudio/deployment/clickonce-and-authenticode?view=vs-2022\r\nPage 2 of 3\n\nSource: https://learn.microsoft.com/en-us/visualstudio/deployment/clickonce-and-authenticode?view=vs-2022\r\nhttps://learn.microsoft.com/en-us/visualstudio/deployment/clickonce-and-authenticode?view=vs-2022\r\nPage 3 of 3",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://learn.microsoft.com/en-us/visualstudio/deployment/clickonce-and-authenticode?view=vs-2022"
	],
	"report_names": [
		"clickonce-and-authenticode?view=vs-2022"
	],
	"threat_actors": [],
	"ts_created_at": 1775434763,
	"ts_updated_at": 1775791326,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/df47235a873681ff000eed5a48e45fa1f5abd8d8.pdf",
		"text": "https://archive.orkl.eu/df47235a873681ff000eed5a48e45fa1f5abd8d8.txt",
		"img": "https://archive.orkl.eu/df47235a873681ff000eed5a48e45fa1f5abd8d8.jpg"
	}
}