Is there a way to choose the specific default client certificate for authentication on web-resources? In the prefs.js in firefox app data folder, there is a line:
security.default_personal_cert
I changed its value to:
Select Automatically
And now it is selecting the first certificate for site avaliable. I want basically to automatate this process (with imacros and few other tools). Is there a way i can set a SPECIFIC certificate as default client certificate? Maybe i have missed somethign else?
It is possible to implement this, but probably not very useful, and I do not believe it is implemented in Firefox.
Servers are usually configured with a specific CA certificate (or set thereof) to use for validating client certificates. The TLS Certificate Request message will usually advertise the Issuer Distinguished Names of these CA certificates in the certificate_authorities field, which the client will then use to select an appropriate certificate to supply in the Client Certificate message. In particular:
If the certificate_authorities list in the certificate request
message was non-empty, one of the certificates in the certificate
chain SHOULD be issued by one of the listed CAs.
An "always use this certificate" option would be useful only in the case where the server does not advertise which CA(s) it intends to use to validate client certificates (I have never seen this situation before). Normally, the Select Automatically heuristic will Do The Right Thing.
If you need an automated way to choose a particular certificate where you have multiple certificates for the same site, Firefox provides the option of multiple profiles. You can have a single certificate in each profile, which will be automatically chosen. It is inconvenient but I do not know of another way.
Related
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 have been using a wildcard SSL certificate for several of my company's B2B websites for some time. Recently, we noticed that Google Chrome started displaying a red unlocked lock with HTTPS crossed out for all of these websites. The solution I found was to reissue the certificate from the provider (Network Solutions). So, I did this, and updated the certificate for each of the websites, and the Google Chrome issue went away (HOORAY!). However, when visiting any of these websites in Firefox, it displays a security message stating the website is using an invalid security certificate:
How can I resolve this so that our users are not confused when visiting these websites?
P.S. These websites are running on IIS6.
It looks as if the certificate chain is incomplete and, thus, Firefox (and likely other browsers) cannot verify the site certificate. Normally browsers store intermediate certificates they have seen in the past - that might be a reason why it works in Chrome.
You can test using https://www.ssllabs.com/ssltest/analyze.html.
Depending on the server software (here, for Apache httpd and other servers which read the certificate in PEM/DER format), you can just paste the intermediate certificates together with the certificate in one .pem file (which is used as Certificate file).
The chain (intermediate certificates) is/are normally provided by your CA. In your case you could also use Chrome the review the certificate and then store/extract all intermediate certificates from the certificate view.
You can get this certificate is not trusted error if server doesn't send a required intermediate certificate.
Firefox automatically stores intermediate certificates that servers send in the Certificate Manager for future usage.
If a server doesn't send a full certificate chain then you won't get an untrusted error when Firefox has stored missing intermediate certificates from visiting a server in the past that has send it, but you do get an untrusted error if this intermediate certificate isn't stored yet.
You can inspect the certificate chain via a site like this:
http://www.networking4all.com/en/support/tools/site+check/
I followed the instructions at enter link description here, to import the intermediate certificates.
In IIS, there is an option under Directory Security to "Enable certificate trust list". I enabled it and added the "AddTrust External CA Root" to the CTL certificates list and this appears to have fixed the issue.
I am having to set up a site with an additional need for security over what I would normally have for an SSL site. To handle this, I am establishing a private CA for the client. Once the import the CA I create as trusted, it will allow them to use the site without SSL errors popping up all the time.
The problem that I have, is that I need to setup the client's browser so that it will notify them if the server certificate changes (browsers won't do this, as long as the new certificate is from a trusted source.)
So, what I am wondering is if there is a browser out there, or a plugin for an existing browser that will allow this functionality.
The Certificate Patrol plugin for Firefox does this (it is active for all sites, not a specific one, but you could easily modify it to suit).
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.
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