removeDomain doesn't remove entry from index.txt resulting in "TXT_DB error number 2" when trying to generate certificates for same host in the future

[wessberg]

Hello there. First, this is a super awesome project!

I'm on mac OS High Sierra.

I've found that when removeDomain is called, only the certificates will be removed. However, since the domain name isn't removed from the index.txt file inside ~/Library/Application Support/devcert/certificate-authority, OpenSSL gives the following error when certificateFor is invoked again in the future with the same hostname:

failed to update database
TXT_DB error number 2

Removing the entry from the index.txt file resolves the issue

[davewasmer]

Good catch! I'm thinking the proper way to do this is probably to actually revoke the cert, which is not what we do now.

[shivekkhurana]

@davewasmer What is the correct way to do it ?

I'm building a ui around this module and want to fix this issue. Ideally I want to do three things to happen automatically :

• Fix index.txt (easy)
• Revoke the cert (don't know how to do this)
• Remove the entry from /etc/host file (easy)

[daniel-crouch]

Is there a fix for this pending at all?

[llwt]

I know this is an old issue, but is there any reason not to setup the ca with unique_subject = no instead of yes to avoid this issue?

If the value yes is given, the valid certificate entries in the database must have unique subjects. if the value no is given, several valid certificate entries may have the exact same subject. The default value is yes, to be compatible with older (pre 0.9.8) versions of OpenSSL. However, to make CA certificate roll-over easier, it's recommended to use the value no, especially if combined with the -selfsign command line option.

This would allow issuing multiple certs for the same domain and be a bit simpler then adding revocation in.

As a, hopefully temporary, fix in our project we modify the generated ~/Application Support/devcert/certificate-authority/index.txt.attr to change the value from no to yes and our tooling begins to work as expected.