Exception error when saving p7mkey file

[SuperlativeIT]

System.NullReferenceException error on the change_click event when saving the p7mkey file. Even after telling the application to continue it writes unusable data to the p7mkey file. When attempting to re-open the database it prompts to select the p7mkey file and then fails to open the database. This occurs on version 1.3 and 1.2b. My operating system is Windows Server 2016 Standard. Please see attached image for error.

I have used both a self-generated x.509 cert using OpenSSL and I have also used a X.509 cert issued by COMODO thinking that maybe it was the way I was generating the certificate. Both methods end up with the same end result.

I tested my Windows 10 pro PC at home and I get the same result.

This issue seems to be procedural. If I go into the KeyManagerUI and first select new key, select certificate from store and then hit save key then the Null Reference error does not occur and the p7mkey saves successfully. Any other order and the Null Reference error occurs.
Even though the p7mkey saves successfully I still get the following error:

[sbidy]

I'll try to reproduce the error. Thanks.

[maiemi]

I can confirm. Same behavior on my Windows 10 Enterprise 1803.
The described workaround is working, too.

[SuperlativeIT]

Further investigation seem to show that the application is not retaining the imported cert info.
Attached are images of the steps I took and the result. I am hoping the images upload in the proper sequence.

[sbidy]

Thanks for the information. I'll have a look into it and see how I can resolve the issue.
One main problem is the "Windows Cert-API" witch is not really stable and well implement in case of smartcars or minidirvers. Also the missing Key-Ring capability of the plugin is also a problem which I have to find a proper solution.

I'm currently busy by other projects but I'll take the time at weekend to give you an feedback or solution.

[sbidy]

fix for #11 can also be a fix for his behavior.

[SuperlativeIT]

I just now tried the 1.4beta and the issue still persists. :(

[SuperlativeIT]

I was able to get past the issue by using OpenSSL to regenerate a new set of X.509 keys.
openssl genrsa -out private.key 4096
openssl req -new -x509 -key private.key -out publickey.cer -days 365
openssl pkcs12 -export -out public_privatekey.pfx -inkey private.key -in publickey.cer

I imported the .pfx into the user's personal certificate store
Opened KeePass and told it to generate a new key, selected my newly imported cert, confirmed a couple of cert prompts, saved the key and database.
I am able to open the database without issue. As a test I removed my x.509 cert from my cert store and I was not able to open the database. I reimported my x.509 cert and I was able to open it again. So as far as I can tell it is working but it would seem that it is very picky as to what and how you generate your x.509 cert. I have yet to test multiple certs so I will let you know on that shortly.

[SuperlativeIT]

I added the second X.509 cert just like I did previously and now have two certs saved. I removed the 2nd x.509 cert from my user cert store since that cert would technically be a different user and I was not able to regain entry into the database. For each X.509 cert I install I am apparently needing all of those certs on my machine before I can open the database.

So I guess this would now become a feature request to allow any one x.509 cert in the list to decrypt the database.