I have generated a csr with:
Requested Extensions:
X509v3 Key Usage:
Digital Signature
X509v3 Extended Key Usage:
Code Signing
If I now generate a csr without the above Requested Extensions: will it still be possible for the CA to add Code Signing usage to my certificate? (e.g. by requesting it through a web form?)
Yes. CAs often ignore extensions from incoming requests (though, depends on CA configuration) and include extensions based on CA configuration.
The only thing CA cannot modify from CSR is public key. Everything else can be changed by CA in issued certificate.
Related
In order to use an EV certificate for CI, GitHub actions offers this action: https://github.com/marketplace/actions/authenticode-cloud-signer
This takes advantage of Googles Key Management System (KMS) to deliver hardware key security with HSM.
The options are pretty self-explanatory except for the certificate option which requires the base64 encoded certificate chain in PEM format.
How does one export the certificate as .pem? I use SafeNet to manage the eToken if that helps.
I have a dsc token, im aware that they can be only signing, or they can be signing and encryption. How do i check?
KeyUsageFlag for X509 certificate is a bitwise flag.
Please refer: X509KeyUsageFlags Enum
There can be a single certificate with both the flag set (addation of values for DigitalSignature and KeyEncipherment) i.e. 128 + 32 or two different certificates. This depends on how Certifying Authority choses to issue the certificate.
How do i check?
Method 1: You must have Smartcard or USB Token driver installed which pushesh Certificates in token to Windows Certificate Store on inserting the token. Then run certmgr.msc to open Certificate Manager; go to Personal Certificates, double click the required certificate to open the Certificate Details and check Key Usage property in Details tab. Values displayed here are in Hex. like: Digital Signature (80)
Method 2:
You may filter on key values and check as above.
Install Signer.Digital Browser Extension as described here
Once Extension is installed and available in the browser, open any site so that browser loads extension script and execute below commands from the console of the browser
SignerDigital.getSelectedCertificate("", 32) - to list only Encryption Certificates
SignerDigital.getSelectedCertificate("", 128) - to list only DigitalSignature Certificates.
Here 32 and 128 are X509KeyUsageFilter values as discussed above.
We are using IdentityServer4 and our version loads the signing key from a PFX file in file system or from the windows certificate store. Using the certificate works. The question is - which certificate issuer should be used in production?
Is a certificate from a public CA recommended? Or is it enough to have a self-signed certificate (without a CA at all) such as it can be created with IIS Manager?
In our tests we have found that the client could still validate the signature in the access token, even if the signing certificate would not have a valid CA chain on the client.
In the docs, it says that you can also use raw key material instead of a certificate:
http://docs.identityserver.io/en/latest/topics/crypto.html#token-signing-and-validation
In this scenario there would be no CA chain whatsoever.
That leads me to the assumption, that when the client loads the public signing key (via the HTTP(s) endpoint), the CA chain information might not be passed anyways. Is that right? Through the loading mechanism via HTTPs you also have a combined security mechanism.
So my conclusion is that for the signing credential a self-signed cert is just as safe as one from VeriSign. Can this be confirmed?
There is no certificate involved in signing and verifying the tokens. Only a private and public key (RSA or ECDSA key).
However a certificate can be useful to "import/transport" the keys into .NET. So, because of that we don't care about who issued the certificate.
When importing the key, one approach is to bundle the certificate that holds the public key + the private key and store it in a PKCE#12 file (.pfx/.p12 extension). Then load that file into .NET. Before .NET 5 working with keys was a bit hard.
The more important thing is that you can manage and deploy the private key in a secure way and that it is persisted over time.
Optionally, you can add support for key-rotation.
I am developing a desktop application. I can code sign it with .pfx file. I will get that from CA. But what if I want to install it in a different system. Will it reflect there as well? Because I can't share my .pfx file with everyone.
You should not share the *pfx as it contains the private key.
The trust to the signature comes from the trust chain - so when the issuing CA and all intermediate CAs up to the root CA are in the trust store (Windows Trust Store, MAC Key Chain or cacerts.pem for OpenSSL/Java) the signature is trusted as long as
the certificate is not revoked
the signature certificate is not expired or the signature contains a counter signature (RFC3161 timestamp).
I have a package that I signed with my own certificate, issued by my own CA.
I signed a nuget package with the certificate.
When I add the root CA in the trust store of the machine, I can verify the signature successfully with nuget, using
nuget verify test.nupkg -Signatures
But, if I remove the root from the trust store, and instead, I add the thumbprint of my certificate as a trusted signers, in nuget, setting allowUntrustedRoot to true, I cannot verify the signature, for some reason.
> nuget trusted-signers
Registered trusted signers:
1. MyCert [author]
Certificate fingerprint(s):
[U] SHA256 - 39544DEE346D61EB2FF5CF4A35EF4B42DE5B4641E1B9AAA098A2A5291F683631
But
> nuget verify test.nupkg -Signatures
Verifying Test
C:\test.nupkg
Signature Hash Algorithm: SHA256
WARNING: NU3027: The signature should be timestamped to enable long-term signature validity after the certificate has expired.
Signature type: Author
Verifying the author primary signature with certificate:
Subject Name: CN=Test Certificate, OU=Test, C=BE
SHA1 hash: 679B1E503720C69D981B9CC4F0199D5D8593375A
SHA256 hash: 39544DEE346D61EB2FF5CF4A35EF4B42DE5B4641E1B9AAA098A2A5291F683631
Issued by: CN=Test Root, OU=Test, O=Test, C=BE
Valid from: 10/31/2019 10:29:54 AM to 9/24/2023 11:37:39 AM
NU3018: The author primary signature found a chain building issue: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
WARNING: NU3018: The author primary signature found a chain building issue: The revocation function was unable to check revocation because the revocation server could not be reached. For more information, visit https://aka.ms/certificateRevocationMode.
WARNING: NU3018: The author primary signature found a chain building issue: The revocation function was unable to check revocation for the certificate.
Finished with 1 errors and 3 warnings.
Package signature validation failed.
What's the point of adding a trusted signer and setting allowUntrustedRoot to true if the signature is not verify. I mean, it's apparently enough to add the root certificate to the trust store for the signature to be verified, without doing anything with the configuration.
I would like, if possible, to be able to not import the root CA in the trust store, and only use the configuration of Nuget to verify successfully the signature.
Thanks.
Our belief is that if you tried to use that package in a project with those trust policy settings appropriately in nuget.configs, restore will succeed.
Please confirm that.
Next, nuget verify has a -config switch -- please try passing in the path to your nuget.config.
If the first test works, and the second test doesn't, nuget may have a bug in the verify command. If so, please file an issue at https://github.com/nuget/home/issues/
-Rob Relyea (NuGet Client Team)