Despite doing a extensive search, I cannot find any examples of setting custom extensions (the CustomExtensions property) on a X509 (v3) certificate.
If I want to generate a new certificate (based on an existing CA certificate already installed on the machine), how can I add custom extensions to it? I am looking to carry some extra custom information around in the certificate for later inspection. Can this be done programmatically or by using makecert? Or can these extensions only be set by writing a custom policy module that is invoked when the certificate is generated? Can this even be achieved by using the regular X509Certificate or X509Certificate2 classes from the .Net framework?
I have found code to inspect the custom extensions, but none to set it.
Whatever existing certificate you have, it's "sealed" by signing. Changing their contents invalidates the signature and consequently the certificate. That is why you couldn't find any information about what you want to do.
What can confuse you is custom properties of the certificate when you view it via Certificate Management snap-in in MMC or when browsing certificates in Internet Explolrer. Such properties are not stored in the certificate - they are kept by CryptoAPI separately, not "embedded" into the certificate.
For self-signed certificates for which you have a private key you can re-create the certificate and have custom extensions added to it, but this is a rare case. I am not sure that .NET Framework lets you work with custom extensions, but our SecureBlackbox does.
Related
I recently had to take over an Excel plugin project and one of the issue I'm getting is that a customer can't use the plugin because their Trust center only allows COM add-ins signed by Trusted publishers. (And they are not able to disable it)
I'm quite new and don't really understand this signing issue so I self-signed the code.
But the add-in has its publisher set to None. Here's how it's showing.
I believe that's not what I need to do, right? As a self signing will not be trusted by the customer Trust Center.
I saw this post but I was quite unsure about what was going on.
Does that mean there is no possible workaround or am I getting this wrong?
One thing I was wondering but I needed some help over is that if the add-in needs to be signed by a Trusted publisher.. Would that do the trick if the client is generating .pfx and I use it to sign the add-in?
AFAIK, there are no "tricks" you can do from the DEV side. This is a security feature. You need to sign your add-in with a valid certificate to get rid of "unknown publisher". You can do that by selecting that certificate on "Sign" tab in Project settings in Visual Studio.
If you are a public company/developer and don't really have any assumptions about your users, then you can obtain the code signing certificate from one of the public code signing certificate providers. The main ones are listed here: https://learn.microsoft.com/en-us/windows-hardware/drivers/dashboard/get-a-code-signing-certificate
It is not free, and you'll need to prove your identity to the certificate issuing authority (like, provide them your passport/company registration details/etc).
If you are developing an add-in for a specific organization and you can negotiate with it's admins, or your users have admin rights on their computers and are allowed to mess with security, then you can create a self-signed certificate, sign your code with it (select it on "Signature" tab), and then ask your users (or user's admin) to add this self-signed certificate to "trusted root" for their organization/on their PC.
Please note that self-signed certificate usually work only on the PC where the certificate was created, and used for testing or development purposes. In your case, this means that your self-signed certificate is considered valid on your PC, but not on the customer's PC. If you want a certificate created by you on your PC to also work on customer's PC, then you'll have to ask the customer to add your certificate as "trusted root", i.e. to treat your signature the same way as one of those "worldwide trusted certification authorities" from the list above.
The normal practice is to buy a certificate from the certification authorities though.
We have developed a web application that generates an xml file. To deploy the application to production, we have purchased an SSL certificate through DigiCert, so that it runs under HTTPS protocol, however, one of the requirements are to send the xml file with a signature to be verified by the receiver (client), that it is in fact a genuine xml document sent from our service.
Do we need to get a document/code signing certificate too to achieve this, or is the SSL certificate we have purchased sufficient and to just follow this Microsoft tutorial:
https://learn.microsoft.com/en-us/dotnet/standard/security/how-to-encrypt-xml-elements-with-x-509-certificates
The X509 XML signing code can work with any X509 certificate. From the coding perspective you can use the one you already have unless your client demands you to use a cert generated from a specific CA.
The code you linked does encrypt an XML, but you stated you did need to sign it. They are different things.
Encrypting does make it unreadable to anyone that does not have the private key.
Signing does a signature of the content and adds it at the end of it, so anyone can check the content was not altered.
I have created a Self Signed Certificate using makecert.exe by reading the following msdn link:
https://msdn.microsoft.com/en-us/library/ff648498.aspx
But, the Certificate created using the command examples mentioned doesn't have any CRL Distribution Point in the Certificate created, which is why when running my WCF service, I get an exception that - The revocation function was unable to check revocation for the certificate.
How can I create a Self Signed Certificate that also has a CRL Distribution Point inside it, so that I don't have to use, revocationMode='NoCheck'?
Is it even possible using makecert.exe? and if not, How can I do that?
If you're fine with doing it manually for the certificate generation, I use a program that helps with that, XCA. It's an open source utility for managing certificates, keys, signing and CAs, with far more options than makecert.
It lets you create a self-signed certificate with full control over each data it contains, one of such fields being the CRL distribution points:
I have no idea if makecert is actually capable of that, or how to do it, but for me using XCA is fine, and certainly possible to meet your requirement.
How can I read certificates from a PKI card?
I tried finding answer on the Internet but I didn't get any good results.
Any ideas how to get the certs from a PKI card?
I need to sign some forms with a certificate key. All this will happen in a web app.
Later...
I didn't tried much because I don't have a point to start. I've just learned that all of the certs are read by Windows when you insert the card. This way I think I can get them using X509Store. I'll try it and I'll be back but still I'm in the need of some help.
As soon as you plugin in your SmartCard the certificates are copied to your local, personal certificate store. You can use "certmgr.msc" (run -> enter) to have a look at these certs.
You can access the certificates, as well as the associated private keys, with the X509Store. But of course you can only do it locally on your machine due to security reasons. Imagine every website would have access to your private keys...
How to Sign and Verify the signature with .NET and a certificate (C#)
If you are using CAPICOM, you will still need to execute code on the local machine (JavaScript).
You find the following statement here :
[CAPICOM is a 32-bit only component that is available for use in the following operating systems: Windows Server 2008, Windows Vista, Windows XP. Instead, use the .NET Framework to implement security features. For more information, see the alternatives listed below.]
Important None of the alternatives to CAPICOM offer a solution for scripts; therefore, you must write your own ActiveX control. For more information, see ActiveX Controls.
Which indicates that the .Net classes are not a "full" replacement to CAPICOM. So you can't use the "X509" classes in JavaScript.
If you want to use a client side private certificate to sign some data (assume a hash), you need to run code on the client. Here are some ideas what you could do:
Write an ActiveX control
Write browser Plugin(s)
Write an application which can be called by using a custom URI schema (can't post another Link, google it and you will find it).
Of course you need to retrieve the data on the server side and for the last solution you may need a kind of a webservice.
Conclusion
Don't be confused about private and public keys from a certificate.
There are scenarios where you send a certificate to the server for e.g. authentication.
But then its your public key. You should never send your private key around (of course technically its possible).
I have a certificate issued by an official organization to be used for SSL communication, can I use the same certificate to sign my EXEs or DLLs.
If not, what is the critiria for the certificate to be used to sign EXEs and DLLs and other binaries?
A certificate usually has usage constraints, basic constraints and extended constraints (extended key usage, EKU). It depends on those settings what you can use it for. These settings can include client and server authorization, code signing (this is what you're interested in), whether you can use your certificate as an intermediate CA, etc.
Here's a nice overview of possible EKU's: http://javadoc.iaik.tugraz.at/iaik_jce/current/iaik/x509/extensions/extendedkeyusage.html . And basic constraints: http://javadoc.iaik.tugraz.at/iaik_jce/current/iaik/x509/extensions/BasicConstraints.html . The Windows built-in certificate viewer GUI displays all these constraints nicely, in a human readable form, so you don't need to decode OID's or strange field names.
As said in the other answer, X.509 certificates include KeyUsage and ExtKeyUsage extensions, which describe, what the certificate may be used for.
Most (if not all) Certificate Authorities won't issue the certificate valid for both SSL/TLS and for code signing for commercial reasons and also for security reasons.
On the other hand, if you use a self-signed certificate and validate this certificate in your own code, then nothing prevents you from generating the certificate with KeyUsage set to what you need and validating it accordingly.