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.
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.
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.
I am developing an office add-in application. We want to try the auto update function of the ClickOnce in the Visual Studio.
This is our first time to publish the software online. And we used a certificate created by ourselves to sign the software. We met a problem. we put our software on our server, when we try to run the .exe file after we download this file from our server.
It gives the below error:
Customized functionality in this application will not work because the
certificate used to sign the deployment manifest for wordadd or its
location is not trusted. Contact your administrator for further
assistance.
Then we export the certificate created by the developer and import into the computer that we want to download the software. It would not show above error. It also can auto update. But we cannot ask our users to do this. It really inconvenient ask our users to do this. So we just wonder that whether this problem can be solved if we buy the certificate from the certificate provider.
Below is a question also about this problem, they still have this problem even they already bought certificate.
Cannot install ClickOnce - Certificate Not Trusted
Buying a code-signing certificate greatly increases the chances that your software will work as-in on your users' machines, but in the end it all boils down to the following question
Is the certificate used to sign this application trusted by the machine?
The answer to that question is a definite no for your self-signed certificate, but it's not guaranteed to be yes for the certificate you'll buy.
The big / reliable certification authorities are trusted by default on most machines (see the Trusted Root Certification Authorities store on a Windows machine), but if your user (or big-corp's IT) removed the default authorities from the certificate store you're back to square one and you'll have to ask the user to explicitly trust your certificate. There's no easy workaround!
In the end, buying a certificate from a trusted CA will solve your problem on most machines but it's not bullet proof. You should be ready to support users who don't trust the default CAs by telling them to import your certificate.
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.
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.