I had a similar experience. Any modification to the database with certutil
suddenly made the legacy database error pop up. I assumed it was some
change in the underlying system or certutil utility. The cleanest way I was
able to get it to resolve it was to create a new, empty database in another
Am 2020-08-24 16:13, schrieb Rob Crittenden:
Mark Reynolds wrote:
I think the issue was that the new certificate "might" have had the
same
name as the old one?
I suspect it's because a new private key was generated there are two
certs with the same name but different keys.
To re-use the
Mark Reynolds wrote:
> I think the issue was that the new certificate "might" have had the same
> name as the old one?
I suspect it's because a new private key was generated there are two
certs with the same name but different keys.
To re-use the existing private key the easiest way is to simply
I think the issue was that the new certificate "might" have had the same
name as the old one?
On 8/24/20 9:28 AM, rai...@ultra-secure.de wrote:
Am 2020-08-24 15:18, schrieb Mark Reynolds:
Not sure what the problem is, but if you create a second test DS
instance, can you import it there?
Am 2020-08-24 15:18, schrieb Mark Reynolds:
Not sure what the problem is, but if you create a second test DS
instance, can you import it there?
Maybe remove the old cert first? If you try that though please make a
backup of these files under /etc/dirsrv/slapd-INST: cert8.db, key3.db,
and
Not sure what the problem is, but if you create a second test DS
instance, can you import it there?
Maybe remove the old cert first? If you try that though please make a
backup of these files under /etc/dirsrv/slapd-INST: cert8.db, key3.db,
and secmod.db in case it doesn't work.
HTH,
Mark
Am 2020-08-24 09:24, schrieb rai...@ultra-secure.de:
Hi,
[...]
Now, I tried to list the private keys with -K, I get
certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The
certificate/key database is in an old, unsupported format.
Ah, forget the "-d" switch.
I can list the private
