Hi Dave and Andreas, about the different clients: we have also seen some trouble using the certificates with different browsers, and the error messages shown by the browsers often are really misleading, if not totally wrong. Firefox usually worked quite well, however, you have to import the CA certificate into the clients certificate store. Firefox uses its own certificate store, whereas Internet Explorer or Safari use a system-provided store (on Mac there is a keystore utility to handle certificates, safari for linux in turn implements its own certificate infrastructure). Chrome, if I recall correctly, uses the windows-certificate store, and something own if installed on Linux.
Often the CA certificate is imported, but sometimes it does not receive the appropriate trust settings. With IE we had cases where we had to throw the CA certificate out of the windows-Keystore and manually had to re-import it explicitly (from a pem-file) into the trusted Root Ca category. About the other points (I don't have any experience with SCEP in particular), but I have noticed that some services in the CA interface do not start automatically (even if you check the checkbox for this). In our case it is the auto-CRL issuing for example, but this is a service which asks for the password of the private key. I have seen that there is also an auto-Certificate issuing. Maybe this is needed for the SCEP? Migrating the dbm files: Could you export/create a backup in the node interface of the old ca installation? Maybe this puts all certificates into a tar archive? Or they are stored somewhere on disk? Quite a painful procedure would be to copy-paste them from the listing of issued certificates in the RA web interface. We were lucky that we had full backups of all pem files for certificates and requests. Using those I could modify the import scripts in src/scripts/*import* (actually I have explicitly passed the authentication details to the "new OpenCA::DBI" call, which was sufficient to make these scripts run from the command line. This way I could populate the database. Admittedly, this is not the way a restore should be done, but in our case I had to find a way to import pre-existing data generated with the same key but a different CA-software. I hope that (at least some of) these hints may help you Martin On 08/19/2014 12:54 PM, Andreas Krieger wrote: > Hello Dave, > > I have noticed that when I'm try to approve and sign the reuqests via > Iceweasel browser of my debian system I get > the Error: Digest mismatch. Signature is wrong. > > Same when I use Firefox on Windows XP but when I do the same with the > Internet Explorer 8 it works fine and th requests are signed and approved. So > I think it is a problem of the browser. > > Is the Batch processing working on your site? Because when I try to Issue the > certificates via the Batch processing it doesn't issue any certificates. I > can issue them manually. > > I also have another question about the approval of the requests. Our OpenCA > 1.0.2 is approving the reques automatically when we send certificate requests > via scep. The same with my new installation of OpenCA 1.5.1 is not auto > approving the requests with the same sceo request. > > Thats the only 3 things we have to manage: > 1. auto approving certificate requests that are sent via scep > 2. the batch processing (are there any log files abot the batch processing?) > 3. migrating the old DBM files into the PostgreSQL database > > I have tried to change the data field forthe key from varchar (60) into > bigint as the datafield is in the PostgreSQL database of 1.0.2 but i doesn't > work because the varchar value dosn't fit into the bigint. > ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Openca-Users mailing list Openca-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openca-users
