I understand how SSL works, but my question is more regarding the storage of certs on client side. To understand the exact context you can assume that I am sort of writing my own browser.
My Rendering part will be done by WebKit and http request handling part will be done by libCurl. libCurl has an option called CURLOPT_CAPATH using which i can tell one folder location to libCurl and that's what libCurl will refer to for perhaps trusted certificates authorities. But I do not know which location is that? IS it operating system specific, my browser sort of app is suppose to work on multiple plateforms.
Where OSx and Windows keep their certificates?
Is it one unified directory ? or its splitted in multiple locations?
Windows keep them in registry not in directory?
multiple browsers on same operating system use the same certificate store or all of them have their on certificate store?
Do i need to worry about nss?
Where OSx and Windows keep their certificates?
OS X stores certificates in the Keychain. Windows stores certificates in the Certificate Store.
Is it one unified directory ?
No.
or its splitted in multiple locations?
Yes.
Windows keep them in registry not in directory?
Windows stores certificates in the Certificate Store. Its backed by a file(s), but you don't operate on the file directly.
multiple browsers on same operating system use the same certificate store or all of them have their on certificate store?
It depends.
Firefox and Opera carry around their own collection of trust anchors (CA Certifcates).
Chrome uses the operating system provided store.
Safari uses the certificates in the Keychain.
IE uses uses the certificates in the Certificate Store.
I'm not sure what other browsers do. For example, I don't know from where Iceweasel and Dillo fetch the list of trust anchors.
Do i need to worry about nss?
It depends. What do you have in mind?
... CURLOPT_CAPATH ...
When using cURL, you often use a "ca-certs" file. See Automatically converted CA Certs from mozilla.org.
Related
I'm building a macOS command line app that stores tokens in Keychain as kSecClassGenericPassword. I'm using a self-signed certificate to codesign the app for local development. (I am not adding any entitlements.)
The problem is what whenever I re-compile (and re-sign) the binary, I get a prompt for my admin password whenever the binary accesses the keychain item. According to this answer, keychain should detect that both versions of the binary are signed and have the same identifier, and not ask for my password. Is there anything I'm missing or any workaround to avoid having to enter my password so frequently?
I don't know for sure, but I strongly suspect the issue is that your certificate is self-signed. Most security decisions in macOS are based on the team identifier embedded in the signing certificate. This prevents a malicious program from stealing credentials from another application simply by giving itself the same bundle identifier and being signed. For the authorisation check to be skipped, both the bundle identifier and the team identifier must match.
I suspect that even if you did somehow embed a team ID in your certificate, because the certificate is not in turn signed/issued by Apple, the team ID would (rightly) not be considered reliable by the OS, so your binary is treated as effectively unsigned. I suspect the CDHash (cryptographic hash of the binary code) is used for authorisation instead, and your certificate is ignored.
I don't know your reasons for using a self-signed certificate, but as far as I'm aware you can get a very basic Apple Developer certificate from Apple for free, and using this to sign your binary should suffice for solving the issue you are encountering, as the free certificate includes a Team ID.
The only other workaround I can think of is to use a helper process with the sole purpose of storing and retrieving the credentials, and using XPC to communicate with this from your main binary. The helper process would hopefully not need to be updated as frequently as the main program, so you'd rarely see the authorisation prompt. This is of course still rather awkward, and now you need to secure the XPC service against malicious clients yourself.
I've installed a wildcard SSL certificate for two subdomains that I'm working on for an organization. This is the first time I've worked with wildcard certificates, and I missed installing the intermediate certificate when I first set this up, which resulted in certificate revocation messages when I first tried to load them. I've reloaded the certificates correctly, and both subdomains check out now using http://www.sslshopper.com/ssl-checker.html.
The sites appear to load fine everywhere except on the two machines (Mac Laptop & Vista Desktop) that I use to develop on, where they're still showing revoked. I've tried to refresh my local CRLs using the following commands:
certutil -setreg chain\ChainCacheResyncFiletime #now (Vista)
and
crlrefresh r p (mac)
I've restarted both computers and cleared browser caches but am still not able to access. How can I get my local machines to forget that the certificate was initially revoked?
I needed to ask the organization I'm working with to regenerate the certificate. I installed that one and everything's good to go now.
I distribute a Windows desktop app which has all executable files digitally signed by a Verisign Class 3 Code Signing certificate. For the vast majority of users, this seems to work fine.
However a small number of users report the certificate is invalid. They say it comes up with the message "A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider". This corresponds to error code CERT_E_UNTRUSTEDROOT (0x800B0109). This has also been reported on a fully-updated Windows 7 machine. So presumably my certificate is OK, but Windows sometimes doesn't trust VeriSign certificates.
Why does Windows sometimes not trust VeriSign? Is there anything I can add to my installer (also signed) which will tell Windows to trust the certificate?
There are frequent updates of the Root Certificates which Microsoft rolls out via Windows Update, but which are tagged as "optional update". Hence not all users may have them installed and may need to install them manually. This also holds for "fully updated" machines, as the automatic installation is often set to only install "important updates", which the Root Certificate updates are not.
Depending on the type of desktop application, you may have to follow certain rules when signing, too. For example applications interacting with the Windows Security Center require essentially the same signing method as drivers. That is, the certificate chain gets embedded along with the signature (/ac switch to signtool). You can get the MSCV-VSClass3.cer applicable to VeriSign certificates here.
The process is often called cross-signing, which seems to be a misnomer. While this is one step in getting your driver binary or catalog cross-signed, the vital step is that Microsoft signs the driver (or more usually the catalog file these days), which is the actual cross-signing.
I'm working to upgrade our source control from hg 1.6.0 to 1.8.2 and I'm looking to set up and use SSL certs. This is on a Windows Server 2008 Enterprise system running IIS 6.0, not my server so I need to use those versions of software right now. All my users are running Windows too.
To ease installation/configuration for my users I'd prefer to modify the Windows Cert Store instead of the cacert.pem file. Does Mercurial have access to the Windows Certificate Store? It doesn't seem to. I am using internally created certificates and I can get things to work without SSL warnings by adding my root cert to the cacert.pem file in Mercurial but I can't seem to get it to work by adding the certs to the Windows Cert Store. Am I missing something?
Thanks,
Scott
No, Mercurial does not access the Windows certificate store.
It includes in its distribution a cacert.pm (as you know, even though before 1.7.3, the story was a bit different)
The article "X.509 certificates and Mercurial" has more information.
A principal thing to remember here is that Mercurial will not work as a complete server out of the box, requesting authentication information, in the form of basic, digest, or certificates, at all.
This means that in order to use X.509 certificates with Mercurial, one needs to place a web server that knows of these authentication mechanisms in front of it.
This article includes makecert.exe, which actually knows about the Windows certificates store (contrary to Mercurial itself)
makecert.exe is a bit of a different beast from openssl as it interfaces directly with the machine’s or user’s certificate store (the special place where certificates live a happy life in Windows).
Greetings,
I am responsible for a Java Applet that needs to work on a wide range of Macs. This applet needs access to the file system and thus needs to be signed. On a Mac, even if the applet is signed and the certificate is valid, by default the applet will still not work. You need to open the certificate and put under the trust settings 'Always Trust'.
To know what I am talking about, see mac docs,
Figure 3-3
Now, after installing the most recent update of Java on Macs, the trust section no longer appears and people who visit the site for the first time cannot get the applet to work any more. Any help, ideas, suggestion are very welcome.
T.
Maybe the original certificate (or one of the signing CAs in the certificate's path) is no longer valid. Check dates of all of them in the whole cert path, not just that of the cert itself.
This is fortunately no longer a problem on current OS X Lion.