This essay does not describe an existing computer program, just one that should exist. This essay is about a suggested student project in Java programming. This essay gives a rough overview of how it might work. I have no source, object, specifications, file layouts or anything else useful to implementing this project. Everything I have prepared to help you is right here.
This project outline is not like the artificial, tidy little problems you are spoon-fed in school, when all the facts you need are included, nothing extraneous is mentioned, the answer is fully specified, along with hints to nudge you toward a single expected canonical solution. This project is much more like the real world of messy problems where it is up to you to fully the define the end point, or a series of ever more difficult versions of this project and research the information yourself to solve them.
Everything I have to say to help you with this project is written below. I am not prepared to help you implement it; or give you any additional materials. I have too many other projects of my own.
Though I am a programmer by profession, I don’t do people’s homework for them. That just robs them of an education.
You have my full permission to implement this project in any way you please and to keep all the profits from your endeavour.
Please do not email me about this project without reading the disclaimer above.
Users need the most recent root certificates in order to use Applet or a Java Web Start code signed by recently issued code-signing certificates or ones signed by certificates from obscure companies whose root certificates are not included in the Sun distribution.
Without wide distribution of the corresponding root certificate to all the software users, a purchased code-signing certificate behaves just like a self-signed phony one.
In particular the Thawte Code Signing CA.cer root certificate is not part of the Java 1.4 JRE (Java Runtime Environment) distribution.
It may even be possible to get all your root certificates from all the signing authorities updated in one go from a trusted third party. In the worst case you would have to visit each signing authority’s website and run their version of the application.
I propose writing a generic fully automated root certificate updater called inject.
The program has no user interface, other than perhaps to ask for final confirmation and a display of how successful it was. The user does not have to answer any questions, much less complicated ones.
It uses the Java Security API (Application Programming Interface) or exec to launch native utilities to make the necessary modifications. Ideally it would be completely platform independent.
The program finds the current cacerts. file and updates it. It can scan for others and optionally update them too.
A more difficult challenge would be to also update the root certificate databases in the various browsers such as Opera, Mozilla, Netscape and Internet Explorer.
For ultra security, Sun and the root certificate authorities could jointly invent a special sort of certificate that enables a program signed with it to meddle with the cacerts. file, but only of that company.
As corporations convert from clear text http: communications to secure https: communications, there is a problem with Java. It needs the root certificates of the CAs that issued the SSL certificates installed in cacerts. It is technically the same problem as code-signing certs, but much bigger. Java comes with some of them installed. But with out the root, you cannot communicate with someone using an unknown CA.
What you want is a tool for installing (and removing root certificates.). Have a look at my root certificate page. It will tell you places on the web to look for root certificates. You want to get them from official sources. You create a list of root certificate download URLs (Uniform Resource Locators). The user just ticks off which ones he wants to install. Your program downloads the needed ones and deletes the no longer desired ones. You would also allow him to install a certificate from local hard disk.
If a certificate authority is not careful about who is gives certificates to, you might want to disable that CA, by removing his certs from cacerts, but possibly keeping them in a backing store for quick reinstall.
You could exec keytool.exe to do the work. However, it is only available on machines with JDKs (Java Development Kits) not JREs (Java Runtime Environments). You are best to use the API.
You will find root certificates in the form of *.cer or *.crt files. They contain an X.509 certificate. These can be in binary (ASN.1 (Abstract Syntax Notation 1) DER (Distinguished Encoding Rules) ) or it can be encoded with Base-64 and have a header and footer applied ( PEM (Privacy Enhanced Mail) ). *.bundle.txt files may contain a bundle of Base-64 certs. You will have to support the various formats used out in the field, including zipped bundles.
Windows has a repository of root certs as does Java. Java normally ignores the Windows repository. So adding a cert to the windows repository does nothing to help Java. However it is possible for Java to manipulate the Windows repository in a not totally satisfactory way to use, add and remove certs. Your installer should let the user control separately where the root certs are installed.
Those concerned with high security would not want to trust such a black box to update their certificates, but for the majority of users, they would vastly prefer the convenience and simplicity.
 |
This page is posted |
http://mindprod.com/project/rootcertinstaller.html |
Optional Replicator mirror
|
J:\mindprod\project\rootcertinstaller.html | |
 |
Please read the feedback from other visitors,
or send your own feedback about the site. Contact Roedy. Please feel free to link to this page without explicit permission. | |
| Canadian
Mind
Products
IP:[65.110.21.43] Your face IP:[3.145.107.223] |
| |
| Feedback |
You are visitor number | |