Serious issue when signing a database in the background on the server

January 31, 2015 – 2:01 pm

While working with the cAPI, I ran into a nasty problem with signing design elemnts in an application on the server with a different ID than the server ID.
This seems only to be a problem with XPages related design elements.
When you try to open an XPage from that database in the browser, you will get a 403 Error message.
When I sign the same database from the client with the same ID using Ytria SignEZ, everything works as expected.

Other elements are not affected. So forms, views, agents and script libraries are signed correctly. Well, don’t get me wrong, even XPages are signed correctly, but they just do not work any longer after signing.

So, how do I sign a database in the background on the server with a different ID?

Here is, what I do. The ID is stored as an attachment in a configuration document. The file is detached at runtime to a temporary directory outside the Domino installation path. The code opens the file and returns a handle to the ID

if ( NOERROR != SECKFMOpen(&hKFC, 
                SECKFM_open_All, 0, NULL))

An XPage is defined by NOTE_CLASS_FORM and DESIGN_FLAG_XSPPAGE, so later in the code, we have to open the note EXPANDED

ret = tnote.open1(tdb.hDb, nid, OPEN_EXPAND);

Finally, the design note is signed using NSFNoteSignExt3

ret = NSFNoteSignExt3(
      tnote.h, hKFC, NULL, MAXWORD, NULLHANDLE, 

and contracted afterwards

ret = NSFNoteContract( tnote.h );

To verify, if anything is wrong with the signature, I use

ret = NSFNoteVerifySignature (
      tnote.h, 0, 0, retSigner, retCertifier);

So far, so good. As I said before, the code runs without any issues and the verification also does not report any errors.

At ConnectED, I went to the “Meet the Developers Lab” and asked for advice. The problem seems not to be in my code, but the Devs had a vague idea, what might be the problem.
I did some tests today and here is what I found out.

When you sign a design element using the client, The last entry in the $UpdatedBy field is the name of the signer.
When you do the same on the server, then the server’s name is the last name in the list.
Hence it is different from the name that is stored in the $Signature field, the error occurs.
This also explains, why I can open XPages that have been signed using my code and the server ID instead of the signer ID. In this case, names in $UpdatedBy and $Signature are identical.

As far as I can see, there is no workaround for that. So the only way to get this solved is to open a PMR with IBM …

Sorry, comments for this entry are closed at this time.