03 Troubleshooting
Administrator Client, Client, Server
Adminp fails to write public key during recertification/expiration
This is targeted to be fixed in R5.x. There are no plans to fix this in R4.x.
The following steps show that the Admin process fails to write the same public key to the Person document and User ID during authentication:
1. Register a new user.
2. Check to see when the certificate expires - (my test - 03/31/2000).
3. Compare public keys from User.ID to the person doc in the NAB, the public keys should be the same.
4. From the NAB, select the new user's Person document and click Actions->Recertify Person and for testing purposes. (I entered a date later than the default to verify that the ID gets updated (03/31/2010). Click the Certify Box.
5. From the Server console, type "Tell Adminp process all." The request is processed in the admin4.nsf.
6. Check the certifier expiration date on the user.id. The date is 03/31/2000 which is expected since authentication has not occurred yet.
7. Authenticate with the server. The message, "The hierarchical certificates in your ID file have been updated with new expiration dates" appears.
8. Look at the user.id and the new expiration date is present (03/31/2010) - but comparing the public key in the User.id and the person document reveals that the second grouping of characters is different.
9. From the administration panel, choose certify ID file.
10. Select the certifier, then the same user.id, and set the expiration date to (03/31/2020) and certify.
11. Compare the public keys between the User.id and that in the corresponding person document.
The User's ID now has matching public keys in the ID itself and the Person document in the NAB, with a certifier expiration date of (03/31/2020). The problem with the above scenario is that if an administrator wants to make the certificate expire on a user's ID via the admin process, by placing a certification date in the past (I tried 03/31/1997). The request is then generated in admin4.nsf, and appears to be successfully processed. The certlog.nsf is updated. When the user tries to authenticate, there is no message: "The hierarchical certificates in your ID file have been updated with new expiration dates," the ID file is never updated and the certificate still reflects the later date:
1. Select the same user, and click Actions->Recertify and place the expiration date back to (03/31/2001).
2. From the Server console, type "Tell Adminp process all." The request is processed in the admin4.nsf.
3. Check the certifier expiration date on the user.id. The date is 03/31/2020 which is expected since authentication has not occurred yet.
After authenticating with the server and with the User.id, THERE IS NO MESSAGE: "The hierarchical certificates in your ID file have been updated with new expiration dates." The User.id still reflects the expiration date of 03/31/2020.
If you compare the public key is the User.id with that of the Person document, the second grouping of characters is again different.
At this point, the public keys are different in the Person document and User.id. There is an expiration date of (03/31/2020) on the user.id:
1. From the administration panel, choose certify ID file, select the certifier, then the same user.id, and set the expiration date to (03/31/2004) and certify.
2. Compare the public keys between the User.id and that in the corresponding Person document and they are the same. The expiration date upon examination of the ID file is (03/31/2004).
If select an expiration date in step 1 of (03/31/97) and certify, the public keys via the user id and person document would be the same. When the user.id tries to authenticate with the server, the user is locked out because the id is expired.
Topics