Windows 11 Digital License

[Perpetuo Carlson]

HoweverI have a question. I have at least 3 PCs in my house with the same Microsoft account on them. Presumably, all of them have digital license linked to this same Microsoft account. I wonder if there is a centralized place to check all my digital licensed connected to my Microsoft account?

As you have installed (and activated) Windows 10 on 3 PCs,Microsoft now holds in its activation database threedigital licenses for each of the computers by their hardware.Upon reinstalling Windows 10 on any of them, activation willbe immediate once Windows gets in touch with the Microsoft servers,no matter which account was used to login, Microsoft account orlocal account.

There is no connection between your Microsoft account and itsstored digital licenses, if none of these licenses was everinstalled on the current device.Go toaccount.microsoft.com/devicesto see a list of all the devices associated with your Microsoft account.

We recently tried out digitally signing our .NET binaries. We have a Windows Service which typically starts up within 10 seconds. However after we started digitally signing it, the time increased to around 20-30 seconds.

But the description of generatePublisherEvidence on MSDN points to the fact that this is not applicable for .NET 4. Still I tried out this setting and it did work. I double checked that my binaries do target .NET 4.

I was in a similar situation: An authenticode-signed application on a server without internetaccess had an unexplained significant startup delay. Setting the generatePublisherEvidence tofalse seemed to solve the issue, but I was unable to a definitive explanation of why this wasnecessary.

The generatePublisherEvidence element is definetely still relevant for .NET 4, even 4.7 which I was using!It is just no longer the case that without it the signature is always verified by the runtime as part ofthe assembly loading process, but the signature verification might still be triggered (unintentionally) at some point!

A digital signature would always be verified when an assembly was loaded, as part of theinitialization of the so-called evidence objects used by the Code Access Security (CAS) mechanism.The publisher evidence, which is the one created from the digital signature, was by defaultnot used in CAS, so most of the times this was just a waste of time. And asexplained here:

Authenticode verification adds to the startup time. Authenticode-signed assemblies have to be verified with the certification authority (CA). This verification can be time consuming, because it can require connecting to the network several times to download current certificate revocation lists. It also makes sure that there is a full chain of valid certificates on the path to a trusted root. This can translate to several seconds of delay while the assembly is being loaded.

Consider installing the CA certificate on the client computer, or avoid using Authenticode when it is possible. If you know that your application does not need the publisher evidence, you do not have to pay the cost of signature verification.

The initialization of evidence objects are now delayed until actually needed,to avoid the startup penalty this lead to in previous versions. This means digital signatures are no longeralways verified during assembly loading process. But it turns out there are cases where all evidence objects arebeing initialized, including the rarely used publisher evidence!

In my case I had an application which was using the Oracle.ManagedDataAccess library toquery a database on startup. This library relies on a specific configuration section("oracle.manageddataaccess.client") in the application configuration. For some reason I didnot include such a configuration in my app.config file (nor in my machine.config).

When asked for this configuration section, the System.Configuration assembly, responsiblefor accessing the configurations, will first look in the machine.config, and thenin the application config. When it does not find the requested section in either of theseit looks for user-specific configuration files, located in a subfolder path of %AppData%.The full path to these files includes the strong name of the assembly, so therefore thestrong name evidence must be created.

Since my application was digitally signed this included initializing the publisher evidence,which means verifying the signature, with CRL checks and all that comes with it.The publisher evidence is not actually used, only the strong name evidence is part of the path to theuser configuration files, so again this is just a waste of time.

Adding the "oracle.manageddataaccess.client" section to my app.config file avoided this, thecomplete set of evidence objects did not have to be initialized, and the digital signature wouldno longer verified. The startup delay was gone.

In general, setting the generatePublisherEvidence element to false makes sure the publisherevidence is not included whenever the framework decides that the evidence objects must be initialized!

This problem occurs because the application must download the Certificate Revocation List (CRL) for authentication. However, a lack of network connectivity causes the download to fail by timing out. For example, a firewall may potentially block the download. When Windows first starts, the network connection is not yet initialized.

The problem most likely is caused by OCSP and CRL checks being performed for the certificate used for signing. This can increase time significantly. Unfortunately we found no way to disable those checks (and anyway such disabling leads to potential security problems) so we simply don't sign the assemblies with Authenticode but simply strong-name them.

Some software that I download, such as KeepassXC, has a Windows Digital Signature, but they also provide a PGP signature that I can manually verify using a certificate that I get from their code repository.

Well, yes and no. The windows digital signature you refer to is present because Windows requires all executables to be signed. Otherwise Windows will complain that the executable is from an untrusted publisher and Defender SmartScreen will block it. Windows uses it to verify the that the executable has been signed by a reputable publisher (just signing is not enough, you also need a positive reputation). Of course since its signed, the executables integrity is also verified. Almost.

The thing is KeePassXC is software used by security-conscious people. And quite a few of these people are (often right-fully so) extremely paranoid. The problem with the Microsoft Authenticode certificates used to sign executables is that they are issued by CAs trusted by Windows. And CAs can (and have in the past) be hacked or go rogue. So if a CA was compromised, went rogue or forced by a government, they could issue a fake Authenticode certificate under KeePass's name. Then any software signed with it would pass as verified KeePass code, and a fake backdoored but signed version can be distributed to users. That's a risk the paranoid folks would rather not take.

So the solution is to sign it with their own PGP key as well. Now anybody who verifies the PGP signature on the executable can be sure they aren't using a backdoored version signed using a fraudulent certificate.

The Elo ECMG4 Computer Modules feature Intel Core 7th Generation CPUs with enhanced graphics performance. Available with Intel i5 processors for Microsoft Windows 10 or no operating system, the commercial grade computer modules transform Elo's Large Format Interactive Displays into powerful all-in-one platforms. By adding touch to digital signage installations, you can create immersive brand experiences and self-service solutions to help increase customer engagement and satisfaction.

With dimensions of 11.07x8.2x1.7 the new ECMG4 form factor is 47% smaller than the previous model,

delivering a lower cost, lower energy consumption mini pc that's easier to install and maintain.

The Elo IDS Computer Modules slide into the back of the touchscreen display to deliver the industry's thinnest commercial grade all-in-one large format touchcomputers. Field installation is easy with no external cables required. AC power, video and USB signals pass between the computer module and the Elo IDS touch display via an internal docking connector.

The Elo Computer Modules deliver the quality and

reliability Elo is known for and are backed by our

3-year standard warranty with an optional extension

to 4 or 5-years. We design and build the complete

solution, with touch integrated from the start.

Digital certificates bind an entity, such as an individual, organization, or system, to a specific pair of public and private keys. Digital certificates can be thought of as electronic credentials that verify the identity of an individual, system, or organization.

Windows code-signing technologies use X.509 code-signing certificates, a standard that is owned by the Internet Engineering Task Force (IETF). Code-signing certificates allow software publishers or distributors to digitally sign software.

A certificate is contained in a digital signature and verifies the origin of the signature. The certificate owner's public key is in the certificate and is used to verify the digital signature. This practice avoids having to set up a central facility for distributing the certificates. The certificate owner's private key is kept separately and is known only to the certificate owner.

Software publishers must obtain a certificate from a certification authority (CA), which vouches for the integrity of the certificate. Typically, a CA requires the software publisher to provide unique identifying information. The CA uses this information to authenticate the identity of the requester before issuing the certificate. Software publishers must also agree to abide by the policies that are set by the CA. If they fail to do so, the CA can revoke the certificate.

3a8082e126