Owin.dll, the assembly inside the Owin package on Nuget.org, does not have an Authenticode signature. However, on Windows Server 2016 and Windows Server 2019, Get-AuthenticodeSignature (and sigcheck.exe) incorrectly report that Owin.dll does have an Authenticode signature.
If you deploy a Windows Server VM and run this code, it will return different signing and timestamping certificates (I only did this in Azure):
> [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
> Invoke-WebRequest "https://dist.nuget.org/win-x86-commandline/latest/nuget.exe" -OutFile NuGet.exe
> .\NuGet.exe install owin -o .
> Get-AuthenticodeSignature .\Owin.1.0\lib\net40\Owin.dll | Format-List
On Windows Server 2019, it returns a SignerCertificate with Thumbprint AE9C1AE54763822EEC42474983D8B635116C8452 and TimestamperCertificate Thumbprint 893ED0E4D032C3855D5D2296B2DE2DD1AFB897DD.
On Windows Server 2016, it returns a SignerCertificate with Thumbprint E85459B23C232DB3CB94C7A56D47678F58E8E51E and TimestamperCertificate Thumbprint CFC3E3018EA65666DCE484FC7016EB42D1F108A9.
Other certificate metadata indicates that these are, in fact, certificates from Microsoft.
What's going on here? Why does this specific assembly behave this way in these specific versions of Windows?