Since implementing an ID vault whenever I try to register a new user I get the above error. The link below describes the problem I am having but the workarounds do not work for me. Is there something else that can cause this error?
http://www-01.ibm.com/support/docview.wss?rs=899&uid=swg21327353
Subject: disk space
fyi encountered this tonight, turned out the reg server was too low on diskspace!! and that caused the error
for anyone in the future scratching their head…
Subject: SPR CSCT7NKPRQ created <>
Subject: Is there any logging?
Do you see anything in the local or server logs that might provide more detail?
Subject: Log entries
Hi Chad,
Thanks for replying.
The local log shows the following:
21/01/2009 09:23:03 ID ‘C:\Documents and Settings\cchapman\Local Settings\Temp\notesFCBCEE\40072617.id’ failed to upload to vault ‘’ on server ‘CN=Server/O=OU’. ‘Colin Chapman/OU’ made request. Error: Your certificate has not yet been signed by the Certificate Authority. Try again later. on remote server
And the server log shows:
21/01/2009 09:23:03 AM Error processing certificate created by /OU for Test User/OU: Your certificate has not yet been signed by the Certificate Authority. Try again later.
21/01/2009 09:23:03 AM Test User/OU from host [128.10.0.132:3738] failed to authenticate: Your certificate has not yet been signed by the Certificate Authority. Try again later.
21/01/2009 09:23:12 AM Certifying Test User/OU
21/01/2009 09:23:12 AM CA Process (O=OU): Certificate Request processed.
21/01/2009 09:23:45 AM Error processing certificate created by /OU for Test User/OU: Your certificate has not yet been signed by the Certificate Authority. Try again later.
To me it looks exactly like the situation explained in the support document but the workarounds don’t seem to work.
Subject: Response
It’s similar to the Technote, but that would be a harder one to fix. Since CA is handling the stamping of the certificate, there’s a latency between the time where the certificate is created and when it will be signed by CA. In the interim, the client switches to the ID containing the unsigned certificate, which then leads to the error you are seeing. I’ll create an SPR for it, but that might be a limitation of the feature. However, note that this should not impact whether or not the ID can be harvested from the client. You can also register the user without CA, which should work if you’ve implemented the workarounds in the Technote.
Subject: Re: Response
Thanks Chad,
It is not stopping the ID being harvested and I can register users without CA no problem at all so it’s not a show stopper.
As an aside, after I have tried to register a new user and get the vault failure I also then get errors in the server log that the user I have registered is trying to access my mail file. These stop if I restart my client but it looks like the client isn’t switching back to my own ID properly even though I can still access my email etc.
Thanks for your help,
Colin
Subject: Interesting
If I had to guess, I would say the switched user context is still governed by your location document and is trying to poll for mail. As a test, what happens if you go through this procedure using a location document that points to some other mail file? Does the same error occur, just referencing the other file?
Subject: Further testing
I tried your suggestion of creating a new location with another mail file but still had errors about my own mail file. After some further testing it looks like the access errors are happening when the client replicates with the server. Restarting the client solves the problem.