README.md says: testing ECDSA in preference to RSA is typically a feature, not a bug.
Note that recently https://github.com/matteocorti/check_ssl_cert got support to check for valid “3 0 1”, “3 0 2”, “3 1 1” and “2 1 1” records for RSA and EC signature types. This means it can verify, that there is valid a TLSA “3 0 2” record for a TLS connection, when a RSA certificate is requested and obtained and (with different command line parameters) verify that there is a valid “3 1 1” TLSA record for the same destination, when ECDSA certificate is requested and obtained (and also verify any other combination of RSA/ECDSA/any + 301/311/302/211/any).
While testing explicitly by danecheck for RSA over ECDSA can be called a lacking feature, for monitoring TLSA https://github.com/matteocorti/check_ssl_cert is more feature-rich. In pure theory, the lack of possibility to monitor TLSA records differentially for RSA and ECDSA in danecheck, could prevent somebody to offer two types of certificates.
README.md says:
testing ECDSA in preference to RSA is typically a feature, not a bug.Note that recently https://github.com/matteocorti/check_ssl_cert got support to check for valid “3 0 1”, “3 0 2”, “3 1 1” and “2 1 1” records for RSA and EC signature types. This means it can verify, that there is valid a TLSA “3 0 2” record for a TLS connection, when a RSA certificate is requested and obtained and (with different command line parameters) verify that there is a valid “3 1 1” TLSA record for the same destination, when ECDSA certificate is requested and obtained (and also verify any other combination of RSA/ECDSA/any + 301/311/302/211/any).
While testing explicitly by danecheck for RSA over ECDSA can be called a lacking feature, for monitoring TLSA https://github.com/matteocorti/check_ssl_cert is more feature-rich. In pure theory, the lack of possibility to monitor TLSA records differentially for RSA and ECDSA in danecheck, could prevent somebody to offer two types of certificates.