Is it different from any other certificate I can generate via makecert or buy from some authority?
As mentioned by Mile L and Boot to the Head the Extended Key Usage is what determines the purpose that the key can be used for.
Most commercial certificate authorities (Verisign et al) issue certificates for single purposes, or for as few as possible.
They use this narrowing of the puropse to carve out different markets for the certificates and then price them accordingly.
You see them selling different Object Signing certs for Windows Assemblies / Java / Office / Adobe Air etc when (in most cases) the resulting certificate is the same.
For example the Comodo codesigning cert issued here can sign Java applets, WebStart applications, Firefox extensions and even Windows assemblies.
The certificate that's used to sign software is the same certificate that would be used to sign any document. What's different about signing software is where the signature finally resides. In a typical document signing, the signature just gets appended to the original document. You cannot append a signature to most types of software for obvious reasons (some interpreted languages would allow this, but I don't know if it's done in practice).
The solutions to the signature problem vary based on the execution environment. For an executable binary, the signature is often stored in a separate file. In Java you can have a signature embedded in an executable JAR file.
Microsoft has a good reference for an introduction to the signing process.
It depends on what you are doing with it. If you want the certificate to be accepted by a browser in an SSL communication, then it must have a root certificate installed in the browser. The certificates generated by authorities already have their root certs installed in browsers.
If you are using the cert just to sign an assembly, then you don't need it. It depends on who is checking the cert and whether they care if the root is a known authority.
More here:
http://en.wikipedia.org/wiki/Root_certificate
To my knowledge, certificates have a "key usage" attribute that describes what uses the cert is intended for: SSL server, code signing, e-mail signing, etc. So I think it's up to the OS, or web browser, or e-mail client, to check these bits.
When a cert is called into action, the role it purports to perform is as important as identification. It's not just about identity, but also about role authorization. An email protection cert should not be able to perform server authentication. Security concerns dictate a necessary restriction in the power given through a single certificate. The underlying API should enforce the correct usage, be it through the OS or an abstraction such as the .NET Framework.
There are different certificate types because there are very different roles in authentication and authorization that would need them. Allowing different certificate types and hierarchies allow for a model of certificate chains, as found in the "Certification Path" on a certificate. A Server Authentication cert will need to have a top-level CA cert somewhere in the trusted root certificates... or be a part of a family tree of certs which ultimately does. 3rd party Certificate Authorities, I'm sure, price them on a scale of functionality and trust.
Boot To The Head is right... there is an Enhanced Key Usage attribute which provides a description of what the cert claims the role to be (e.g. Server Authentication; or in the case of my CA's cert: Digital Signature, Certificate Signing, Off-line CRL Signing, CRL Signing). Look at the details in a certificate's properties and you'll find it.
I'd also add that a .NET assembly has to be strongly named (which requires it to be signed) in order to be added to the GAC.
There are different types of certs... from the CA that is bundled in Win 2003 server, you can request:
Client authentication
Email protection
Server authentication
Code signing
Time stamp signing
IPSec
Other
Related
I have a Windows image that uses the PowerShell execution policy AllSigned
I also have a PowerShell script that is signed by a signing certificate issued by an internal CA
The certificate of the issuing CA is installed/trusted on the target machine
When I sign the PowerShell script, I am including the full certificate chain (IncludeChain = 'All')
The certificate chain looks like this:
|- Issuing CA Certificate
|- Signing Certificate
The PowerShell script is signed by the Signing Certificate, but we are not installing that certificate on our target machine. We are only installing the Issuing CA Certificate into the Trusted Publishers and other certificate stores.
This method works when we sign our custom application binaries using the Signing Certificate (we use Windows Defender Application Control to ensure that any applications running on our target are signed by trusted publishers) but it does not work when running PowerShell scripts.
According to this MSDN community post, PowerShell uses Known Publisher rules, which state that the Signing Certificate itself has to be in the Trusted Publishers certificate store.
This is not ideal, as the signing certificate we use to sign the PowerShell scripts is not something we want to ship out, nor will it be valid anymore by the time our product ships.
I understand that if I use a timestamp server when signing the PowerShell scripts, that the signature will still be considered valid if the signature was generated within the validity window of the signing certificate, but this is not our preferred solution.
Ideally I would like to know if it is possible, and how, to have PowerShell use the Issuing CA Certificate to validate the signed PowerShell scripts. (i.e. Known Issuer rules)
In the case that it's not possible, I would like to know why Microsoft departed from the practice of allowing you to validate signatures without explicitly trusting the signing certificate (i.e. using the issuing certificate to validate it).
Any help would be greatly appreciated.
There is a difference between deployment and the running of PowerShell scripts.
The confusion is that Windows Defender Application Control can use code signing 2 different ways, for 2 different reasons, and PowerShell has only ever supported one. Windows Defender Application Control can use code signing:
With a trusted Issuing CA Certificate to authenticate applications. This is the situation when your company wants to share many internal applications among all employees easily. It is also used for "trusted" Microsoft Store applications.
Because "normal" people don't blindly trust all applications and generic certificate authorities, you can instead deploy based off of trusting just the Signing Certificate for verification. (see Catalog Files). This is so that you could deploy applications with certificates that may not have an accessible CA. e.g. if you singed the application with an internal CA and you sell it to another company, or if you are using a self signed certificate.
Windows Defender Application Control primary purpose is for Application deployment/control, and a byproduct is that it can do PowerShell scripts as well. Most "normal" applications can run with "invalid" or "broken" certificates with incomplete certificate chains. The certificate was only used to control the distribution of the code and validation that the application was not tampered with/changed, and has nothing to do with the active "running" of the code.
PowerShell, on the other hand, when running with AllSigned, always validates the entire chain before running. It doesn't care about the distribution, it cares about what it runs. That means that the entire certificate chain needs to be present and trusted on the running machine. Yes, that means that if you sign with an internal CA, you need the Issuing CA Certificate, and the Signing Certificate distributed and trusted by the running party.
This leads you to 3 options:
Self signed certificate - This is ok for personal/development projects, and marginally better than distributing unsigned code.
Internal CA certificate - This is ok for internal projects. In this case, yes, you would have to share the entire certificate chain if you wanted to distribute.
Global/Public CA Certificate - This is the recommended method if you are distributing publicly/commercially. The Public CA's are trusted, and code signing certificates can be bought from places like DigiCert and can last 3 years. I know, for me, I would feel much more comfortable running code signed by a DigiCert over having to mess with internal or self signed certificates.
That doesn't make sense.
If the internal root CA certificate is in your trusted root CA store and the intermediate in your trusted intermediate store. Then a PS script is signed by a certificate with a trusted chain back to the trusted root, it should trust the signing of the certificate.
There should be no difference between an internal trusted CA and a public trusted CA.
If anything a code signing certificate issued by an internal CA is more trustworthy than a public signed one. Internal processes and controls mean only actual trusted internal publsihers can get one, unlike a public code signing cert bought for a small amount.
I want my site to be secure using HTTPS protocols. I managed to make a self-signed key to be trustedCertEntry as I made my own CA certificate, with different CN, which I used to sign my own private certificate.
It works smooth testing it with openssl with something like:
openssl s_client -connect www.mydomain.com:80 -tls1 -state
Thus, browser doesn't report a certificate self-signed error, as it sees a different CA.
But I get a SEC_ERROR_UNKNOWN_ISSUER error. Still it seems logical to me as nobody knows me as a CA. It is supposed to work if user adds exception for me.
I thought this trick was acceptable and it was like many https compliant sites were working, as you may visit a unknown site and you want to encrypt communications from 3rd party watchers but trust that page.
After trying to get a clear response for it, beyond coding that I will find resources, my question is:
If I want to have a site, for which the users don't have to add an exception in the first visit, do I have to get a certificate from a "world-known" CA? Or am I missing a solution for self-signing my certificate with my own CA certificate?
Technically speaking, the answer is: Yes, you will have to get a certificate from a CA that is trusted by your users' browsers via a chain of intermediary CA's that ends at an inherently trusted root CA. The accepted answer to this question explains how it works: SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?
Having said that, if your "only" concern is to provide encrypted connections, you might be able to leverage the Let's Encrypt CA, which provides free certificates for that purpose. Those certificates will be only domain-validated, which provides a weaker kind of assurance of identity than, for example, an Extended Validation Certificate.
Depending on the browser used, there will be minimal difference in user experience between DV and EV certificates. For Safari, the user will see a grey padlock in the address bar for the lower assurance DV-backed sites, like this:
and a green padlock when higher identity assurance is provided, like this:
Whether the former is good enough for you (or your customers) depends on your situation.
In case you want to understand what "inherently trusted" actually means for web browsers, see this blog post: Who your browser trusts, and how to control it.
I Want to authenticate systems deployed on different servers with each others using certificates. If it wasn't a self-signed certificate, what should it be to let each system has its own certificate and trust in in the other server in the production environment?
The signed certificates are paid and I don't think I need them since I don't have user interaction. Am I right?
The distinction here is not really "self-signed" vs "signed." The correct distinction is "commercial" vs. "internal." Commercial certificate vendors are selling you exactly one thing: they have a certificate in the root store of major browsers and operating systems. There is no technical difference between a certificate that Verisign signs and one that you sign. Verisign just has a signing certificate in this list and you don't.
So you're correct. For internal authentication, there is no security reason to favor commercial certificates. You still have to protect your private key just as carefully. Commercial certificates offer convenience, not security. You pay them some money, and you don't have to worry about some of the configuration.
But you can trade convenience for money. There are two ways to do that: internal roots and certificate pinning. With an internal root, you just create some signing root certificate (a "Certificate Authority") and put it in the trusted root stores of your servers. Then issue CSRs (certificate signing requests) to yourself, sign them, and apply those to your services.
Certificate pinning just skips the Certificate Authority step. Just take all of your service certificates, and put them directly into the trusted root stores of your servers. Then there's no indirection.
Each way has its advantages. I tend to prefer pinning all other things being equal because it ties me to specific certs rather than chains. But either way is really fine.
The specifics of course are going to be highly dependent on your toolchain, which you didn't list, but your question suggests you already know how to create the certs.
Just remember that your security is going to be dependent on protecting your private keys. But that was true with commercial certificates, too.
You didn't say what platform you are using, but for Windows I would recommend Active Directory Certificate Services: https://technet.microsoft.com/en-us/windowsserver/dd448615.aspx
I've been struggling recently with using the standalone DartVM and SSL as a client. I'm of the understanding that Dart uses Mozilla NSS to manage the certificates. What I'm having a problem wit, is that on Windows, for example, there exists no binaries that I can find (other than third parties compiling the Mozilla source and uploading to mega or similar, which is pretty alarming if you ask me) released for the Windows platform. Compiling this C++ code is not a trivial task. I've not the resources to do so on my own under the Windows platform. This is why I write Dart (or other high level languages) in the first place.
Despite that, the error message I get when attempting to connect securely and being presented with a self-signed (or rather more technically correct, untrusted authority) certificate, is that the OS itself doesn't trust the certificate. On Windows, this is not the case. The certificate in question I'm using is a CA root certificate of my generating, with proper authority/signing chain, installed into Windows trusted roots manually. Both Chrome and Internet Explorer (of which use the Windows underlying certificate store) trust my certificate(s) without any warnings after having done this. So if the DartVM is not using the "OS" to validate a certificate upon handshake, then that message is very uninformative/misleading.
What can be done to overcome this outside of compiling NSS and trying to figure out just how to import my certificates by way of over-complicated and under-documented steps? Is there not a parameter that one could specify when initiating a secure connection to ignore SSL errors of this nature?
My web server forces the use of HTTPS so dropping back to plain HTTP would
not be an option for me. I also don't want to trust and much less want to pay a third party for my certificates of which are pretty much only used internally, which is why I generated a wildcard certificate under my own root CA in the first place. Paying for a wildcard certificate, for multiple domains, that aren't always necessarily exposed to the public or meant for public use is a bit astronomically priced and completely out of the question.
I am interested in web security right now. So I read about PKI and Diffie Hellman authentication forms.
Now I am reading about certificates and I ask me how that works. So I know Browser have some trusted certificates in it, so you trust the pages, the company which the browser is from, trusts already. So when A trusts B and B trusts C --> A trusts C. Standart Web-of-trust thing.
But what I don't get is how for example google did it when they made there applications https. I never had to download a certificate. How works that?
There are a number of commercial bodies whose business is the issuance of digital certificates; these are called "Certificate Authorities" or CAs. The certificates of the top-level keys of these bodies are distributed with the common web browsers, so you will already have them installed.
If you (or Google, or anyone else) want a certificate for your key you send a request (and some money) to one of the well-known CAs. The CA performs some checks to verify that you are who you say you are, and (as long as the checks check out) they make a new certificare by signing your key with their certificate-signing key.
When you send your certificate to some third party they can check your certificate using the CA's certificate stored in their browser, and this allows them to establish that the identity you claim in your certificate is correct.
There are various levels of certificate which carry different levels of guarantee that the identity claimed in the certificate is correct. Basically, the more you pay the more trouble the CA takes in checking your identity and the more insurance they buy!
All browsers store certificates of Certification Authority, who in turn issue certificates for various organizations.