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.
Related
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 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.
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.
Someone can add a fake SSL cert. into trusted certificates collection. How can I detect these fakes? How can I verify a cert is official, is there any list to compare?
I've added a screenshot of a legal & a fake one (created by Fiddler):
ADDITION:
To ensure your sensitive SSL communication is secure, you have to use certificates of common trusted authorities. If someone installed Fiddler -or a malicious software installed its own cert.- then I need to cancel any communication attempts and alert in my app at client's pc.
ADDITION 2
I only care about communication between end user's pc & Google Docs. We know Google Docs web site's public certificate is given by "Google Internet Authority". I think I have to compare it & installed certificate for Google Docs on user's pc.
Last word:
I need to simply compare the certificate in use for target site vs the target site's original SSL certificate just before any SSL comunication.
More info: This link
There is no single "official list". You must compare your list to someone else's list.
Windows has its own list which is used by Internet Explorer.
Firefox maintains a separate list of its own.
I don't know about Chrome, Safari or Opera.
But the long and short is you need to compare your list to other lists which you know are correct, for example from a colleague's computer.
You can't. If user added it, that means she trusts it. And also, a certificate can be valid without being part of the "official" lists.
Each application maintains (or relies on other applications) the list of trusted root certificate authorities. Windows has its own list, OpenSSL has its own list, all major browsers have their own lists (Chrome uses or can use Windows one, if memory serves).
If you create a Windows application, your best bet is to rely on system list, as it is updated on a regular basis (if you carry your own list, you have to maintain it as well).
One thing to pay attention to is that the certificate issued by trusted authority doesn't mean trusted certificate. Some certificates are issued by hacking (this happened at least with two intermediate CAs during last years), private keys for others are leaked, and this causes the need to revoke such certificates. Revocation status can be checked by inspecting CRLs (revocation lists published by CAs) or using OCSP (online certificate status protocol).
You need to use them no matter where you get the list of trusted CAs.
I am tired of buying SSL Certificates for my clients. We spend thousand dollars per month on average. Can someone please show me how to start my own certificate authority (Not the the self-sign certificate)? This SSL is for IIS.
It seemed like IIS can issue self-sign and OpenSSL can do the same thing and I do not want it unless it can provide a full SSL like Verisign and other big companies.
If you want to roll your own certificate authority (suppose for closed in-company infrastructure), you start by (surprise, surprise) creating a self-signed certificate, which will act as a root CA certificate. Then you generate the first child certificate - intermediate CA certificate. Now put the private key of the root certificate to the safe place - most likely you will not need it for years. Intermediate CA certificate is used to issue end-user (or other sub-CA) certificates.
If you want your certificates to be recognized by standard browsers and other client software, you need to find a way to get your public root certificate to the list of trusted roots in the OS itself and in those browsers and clients, if they have their own certificate storages. This is a complicated procedure, different for each OS and each browser. It involves repeating audits, compliance to tough procedures etc.
Again, if you create certificates for internal company use only, you can make software installer (or just write a custom script or application) that will add your certificate to the trusted root list on each user's computer. This can be done in code almost without problems, but the user will have to (a) run that script or program, and (b) confirm addition of the certificate. For some browsers or other client applications the procedure can be more complicated.
The procedure of creating a CA is quite a complex topic. I suggest that you read some books on PKI before you proceed. Here are the great books I'd recommend:
Rsa Security's Official Guide to Cryptography
PKI: Implementing & Managing E-Security
Creating your own certificate authority is not an issue. Your issue is creating a certificate authority that other people will trust!
There is absolutely no point you creating your own unless all your users are prepared to accept certificates signed by you, and this is a pretty unlikely scenario unless you have a small number of users that are prepared to trust your root CA.
Getting them to trust you involves them all installing your root CA as a trusted CA on their web browsers which is hardly good security practice.
Unless you work in a controlled environment, and all your users are internal, or you have a very suggestible group of users who will do whatever you say - I would recommend you forget this idea.