Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
On AWS EC2 instance, I’m running a custom web server that’s listening on port 443.
I’m trying to renew certificates for subdomains of fbpinningtest.com.
[...]
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator apache, Installer apache
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for pass05.fbpinningtest.com
Error while running apachectl graceful.
httpd not running, trying to start
(98)Address already in use: AH00072: make_sock: could not bind to address [::]:443
(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:443
no listening sockets available, shutting down
AH00015: Unable to open logs
[...]
I was hoping that certbot would start httpd listening only on port 80 to perform its verification. Right now, I have to stop my custom web server, run certbot which starts an httpd instance listening on port 443, then stop it again, and restart my server. That’s annoying. Is there a way to verify on port 80 without having httpd listen on 443 at any time?
Modify your Apache configuration not to listen on port 443.
As far as I know, certbot doesn't add any virtualhost listening on port 443, so I assume it must be a pre-existing Apache configuration file.
But a better question might be: why are you using the Apache authenticator and even the Apache installer when you're running a custom webserver without having a running Apache at all? Why not just use the webroot authenticator? And I'm guessing the Apache installer isn't useful for installing the certificate in your custom webserver, right?
And without any header information about the server.
So if you have an additional Apache, Certbot tries to start that instance if you use --apache.
But port 80 isn't used, so use --standalone and open the firewall. Grade V and an answer < 2 seconds looks like a blocking firewall, not like a simple timeout (> 10 seconds).
No, I manually copy/move and configure the certificates for my custom webserver.
I think when I first ran certbot, it used apache by default (I can’t remember for certain), so I kept using it, turning it off/on.
The /etc/httpd/conf/httpd.conf file doesn’t contain a 443 VirtualHost. However, there’s also a /etc/httpd/conf/httpd-le-ssl.conf file that does contain a <VirtualHost *:443> entry for each certificate that needs to be renewed.
Those were generated by certbots apache plugin when you used to use Apache as your webserver. This setup apparently isn't compatible with your current setup. You should disable httpd-le-ssl.conf, but you'd also need to configure certbotnot to use the apache installer plugin. There's no easy way for that. Either generate the certificate again by using --cert-name <name of cert> (you can find the name of the cert by running certbot certificates) and for example the --standalone plugin as suggested earlier. Or manually modify the renewal configuration file for the certificate to change the installer setting to none and authenticator to standalone.
Yup, good to know. I did just that. Under /etc/letsencrypt/renewal, in each .conf file for each certificate, I changed those properties as you suggested and it now works properly.
I'm pretty sure that's a bug in certbot Did you by accident type null in the renewal configuration file in stead of none? What version of certbot are you using?
Yes. It acts like there actually exists something called the "null" plugin (like the apache or nginx plugin). But no such plugin obviously exists and you can't "reload [the] null server" after a successful certificate issuance, like it showed in your log.
I'll try to reproduce this with the most recent version and if I can reproduce, file a bug report.
Edit:
I can reproduce this bug with the most recent git version of certbot Will file a bug.
Oh snap. While searching if this bug was already filed, it seems to be intentional :
I'm not sure if the reason it still exists is still valid, but hey, at least it's not a bug
Did you by accident type 
Will file a bug.
: