for my $box (@servers) {
  my $ssh = Net::OpenSSH->new($box,
                              user => $user,
                              password => $password);
  if ($ssh->error) {
    warn "unable to connect to $box";
    next;
  }
  for my $certfile (@certfiles) {
     my $output = $ssh->capture('openssl', 'x509', '-in',
                                "/etc/pki/tls/$certfile",
                                '-noout', '-subject',
                                '-hash', '-enddate');
     unless ($output =~ /notAfter=(\S+)/) {
        warn "expiration data not found in $box:$certfile"
        next;
     }

     my $notAfter = $1;

    ...
  }
}
[download]

In no particular order, some additional comments:

• Set up passwordless ssh. Or at least set up ssh keys. With truly passwordless (ssh keys where the private key doesn't have a password), you have to guard the private key, but you can set this up as a cron job with no user input. That means you don't have to remember to run it, which makes it incredibly more useful.

• If you have a lot of systems to check, consider threading/job queue. Personally, I use AnyEvent + AnyEvent::Util::run_cmd to run a dozen or two ssh's in parallel (no job queue - this isn't enough ssh's to matter, but if you have 40+ systems to check, you may want a job queue). If you take the above advice and then put it in a cron job, this may not matter as you can schedule it for a time when it can take a long time and when the network is otherwise not in significant use (e.g., 4AM). If all the systems are on a local Gbps network, this will also not matter. But if some systems are located in other physical locations, possibly with lower bandwidth and/or higher latency, being able to parallelise them can really speed things up. Again, speaking of my personal usage of this pattern, all the machines I ssh to are on a private 10+Gbps network, but the commands can take a long time to run, so I've used AE to parallelise them. In the future, I will likely switch to Coro + Coro::Channel/Coro::PrioChannel for job queuing, though that still leaves AE handling the parallel ssh calls.

  This really depends on what you're doing and how it affects you. If you run it at the command line, as you must right now, you may want to minimise the amount of time it takes. If it's in a cron job in the middle of the night, it may matter less. If it takes 15 seconds, you may not care. If it takes 30 minutes for all the nodes, you may care. All I'm really suggesting is considering it. It's not actually that hard to do with the right modules.

• Send a single message with a list of servers (and their expirations). Rather than flood an inbox, put them all together. Also will generally make it easier to deal with all nodes at the same time. This will require that you save the server and expiration date in an array, then, when you're finished looking at all the servers, you check if you have anything in your array. If so, send the email, otherwise you're done.
• Consider sending the logfile as an attachment. Email::MIME might help here. Rather than having to look around for the log file, just send it. This works even better if you don't send to root, but send to an actual corporate email address where the sysadmin(s) can read it in their normal email program (Thunderbird, right?) with everything else.

but perhaps, you could help yourself with the guides and learn how to post here on PerMonks.

I'd say CUFP. It's our catch-all code section.