Indicate known certificates in sent mails feature

[stoecker]

Fixes #88. I switched from direct parameters to sha256 of the pubkey.

Note that is the first time I do something in go, so it's probably not the best solution (i.e. see todo comment).

Short perl script to create the keylist from public keys and rsa/ec private keys.

#!/usr/bin/perl -w

use strict;

for my $k (@ARGV)
{
  my $name = $k;
  $name =~ s/\.[a-z]+$//;
  $name =~ s/^.*[\/\\]//;

  my $sum;
  if($k =~ /\.pem$/)
  {
    $sum = (split(" ", `openssl x509 -in $k -pubkey -noout 2>/dev/null|sed '1d;\$d' |base64 -d |sha256sum`))[0];
  }
  elsif($k =~ /\.key$/)
  {
    $sum = (split(" ", `openssl rsa -in $k -pubout 2>/dev/null|sed '1d;\$d' |base64 -d |sha256sum`))[0];
    if($sum eq "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855")
    {
      $sum = (split(" ", `openssl ec -in $k -pubout 2>/dev/null|sed '1d;\$d' |base64 -d |sha256sum`))[0];
    }
  }
  print "$name;$sum\n";
}

Final test is still running. I'll update in case I find an error.

[AGWA]

Why send a notification for a certificate with a known key? How would you respond to such a notification?

[stoecker]

By the mail subject I can filter them easily. And I'd rather get them to see system is still working. Others may see that different, so maybe you need some configuration options.

For me that's the near-optimum solution:

• I get mails for new certificates to see all works and when and which certs are updated. These mails go into the "daily status folder" where all others are going.
• When the indicator isn't there it will go into INBOX and needs manual handling.

Without these I'd typically get no mails (for years) and thus system breaking would likely go unnoticed.

P.S. Test run works fine for a known cert. Not yet checked for an unknown one.

[stoecker]

Works as expected on my system properly marking the mails with the correct key-names.

P.S. Maybe it would be a good note in the README, that this tools causes (currently) approx 130GB traffic per day. Could help some people to decide whether they want to install it or not. :-)

[stoecker]

Anything wrong with this?

[AGWA]

1. I think being able to filter legitimate certificates by public key hash is a good feature and plan to add it to a future version of certspotter.
2. Providing assurance that certspotter is working correctly is a very legitimate desire. I'm not sure if sending notifications about legitimate certificates is the best way to accomplish it. Would #97 work for you instead?
3. Since I will be responsible for maintaining the code over the long term, I have to be picky about what PRs I will accept, and I'm not comfortable accepting this PR.
4. Everything done by this PR can be implemented using a custom script so if it's not merged you can still make certspotter do what you want.

[stoecker]

Providing assurance that certspotter is working correctly is a very legitimate desire. I'm not sure if sending notifications about legitimate certificates is the best way to accomplish it. Would https://github.com/SSLMate/certspotter/issues/97 work for you instead?

No. #97 would be no alternative for me.

I wonder about the rationale behind the question. My change is the minimal change necessary to get a desired result. certspotter currently sends a mail for all certificates, so that's nothing new, I only added a flagging with the additional information. Also the added code is nearly an 1:1 copy of watchlist with minor adaptions to the different purpose (most of it removal of code). That was especially done so reviewing is easy and straightforward. All the discussion here indicates that a more complex and error prone solution is preferred, which is strange to me.

Everything done by this PR can be implemented using a custom script so if it's not merged you can still make certspotter do what you want.

You mean that I ignore the certspotter mail sending feature completely and send my own mail (because I see no way to influence the mail which is sent)?

[AGWA]

No. #97 would be no alternative for me.

Could you explain why not?

You mean that I ignore the certspotter mail sending feature completely and send my own mail (because I see no way to influence the mail which is sent)?

Yes. Note $TEXT_FILENAME: "Path to a text file containing information about the certificate. This file contains the same text that certspotter uses in emails"

[stoecker]

Could you explain why not?

My own issued certificates aren't superfluous. I want to know that information. It tell's me:

• that certspotter works
• that the different cert updates work
• which certificates were updated and in which interval
• based on that I know if that matches the expected certificate updates or if I need to review the renewal process.
• if the updates match the deployment (i.e. I get update mails, but later the monitoring complains that deployed certs are outdated)

Yes sure I can create hooks, store that information there or mail it or whatever, but nowadays most of the monitoring feedback goes by email, so that's simply the most elegant way.

[AGWA]

Thanks for expanding on that. It sounds useful and I agree that #97 wouldn't solve it.

Your PR includes the ability to name keys. What's the purpose of that?

[stoecker]

When tracking all certs for a domain (my default), the certspotter mail will inform you about a new certificate for e.g. my.tld. Now I may have multiple different certificates generated for my.tld (ATM my list contains 44). E.g. one for the www server, one for the mail server, one for the bugtracker and version control, one for monitoring system and so on. One generated certificate can contain one or multiple names, but usually it has only one key assigned to it. So the name provided in the keylist can be used to represent that key (for me it's usually the name of the key). I made no limitation to what the name can be, as others may have different opinions about what's useful there (i.e. there could be multiple keys for the same domain on different servers, then the name could be the issuing server).

E.g. you get "Certificate Discovered for .myt.tld (known as mail.my.tld)" and thus know that the mail cert and not the www cert was renewed.

[stoecker]

P.S. My proposed approach is identical to "3 1 1" TLSA records.