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.
My domain is: bios-living.com
I ran this command:
/usr/local/bin/certbot-auto certonly --apache
It produced this output:
Unable to find a virtual host listening on port 80 which is currently needed for Certbot to prove to the CA that you control your domain. Please add a virtual host for port 80.
My web server is (include version):
aps:~ # /usr/local/apache2/bin/apachectl -v
Server version: Apache/2.4.41 (Unix)
Server built: Jan 7 2020 05:36:04
The operating system my web server runs on is (include version):
aps:~ # uname -a
Linux aps 4.12.14-lp151.28.36-default #1 SMP Fri Dec 6 13:50:27 UTC 2019 (8f4a495) x86_64 x86_64 x86_64 GNU/Linux
opensuse
aps:~ # cat /etc/SUSE-brand
openSUSE
VERSION = 15.1
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don’t know):
Yes I can
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): NEVER
The version of my client is (e.g. output of sicertbot --veron or certbot-auto --version if you’re using Certbot):
aps:~ # /usr/local/bin/certbot-auto --version
certbot 1.1.0
I have a custom build of apache. The opensuse tools were totally unacceptable for apache,
modperl and certboot. I didn't use them. Certboot wanted to download Zope -
which is big NO.
I downloaded the certboot from the reular unix instructions - but it INSISTS on
using opensuse binaries and of course it fails. Apache is installed under
/usr/local/apache2
I just rmed the systems useless /usr/local/sbin/apache2ctl
Now I get
/usr/local/bin/certbot-auto certonly --apache
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Could not choose appropriate plugin: The apache plugin is not working; there may be problems with your existing configuration.
The error was: NoInstallationError('Cannot find Apache executable apache2ctl',)
The apache plugin is not working; there may be problems with your existing configuration.
The error was: NoInstallationError('Cannot find Apache executable apache2ctl',
There are some parameters which can instruct the Certbot Apache plugin to use a different installation:
certbot-auto help apache
However … I would suggest not using the Apache plugin with Apache built from upstream sources. At least for other distributions (don’t know to what extend this affects SUSE), it tends to expect your Apache to be configured in the specific manner of your distro’s httpd package.
You can still use Certbot, just in a server-agnostic way, e.g.:
It made a cert, but I’m not certain it it generated that key from a third party or not. What is the different between doing this and just using my signed key that I generated with openssl?
Certbot generates all private keys on your machine (using Python bindings to OpenSSL, in fact), and does not send them anywhere. It also uses a new private key for every renewal, unless you specify --reuse-key.
You can certainly generate your own key (and CSR) using the openssl CLI, and tell Certbot to use that to issue a certificate:
certbot certonly --csr your_csr.pem
but it's not a workflow that supports automated renewal and is rarely used.
For most users, just running certbot --apache should be sufficient, without getting into the weeds about management of key material, how domain validation works, how to deploy a signed certificate to a webserver, how to perform renewal etc.
Then my questions is, how does the certificate get loaded on the certificate authoirty, which seems to be the main point of not doing this as a self-signed cert using openssl which is driving my boss’s broswer crazy with FUD.
Sorry, could you clarify this question? Let’s Encrypt certificates are issued by a publicly-trusted certificate authority and should be accepted automatically by most mainstream browsers and other TLS clients.
A certificate is just a file containing a signed declaration from an external authority that "public key XYZ controls example.com".
Say you generate a keypair on your server, using openssl or Certbot.
When you then use that keypair XYZ to generate a self-signed certificate for example.com, you're signing that declaration yourself - "according to public key XYZ, public key XYZ controls example.com. Browsers have no reason to trust that declaration. I could claim I'm google.com.
Browsers do, however, trust such declarations from certificate authorities. In exchange for this trust, the CAs must perform the task of verifying that you actually control the domain. Once you have proven that control, they sign and send you a certificate. Again, it just contains a signed declaration that "I, Let's Encrypt, assert that public key XYZ controls example.com".
Then when your webserver presents that certificate file to a browser, the browser sees that the domain matches, that it trusts the signer (Let's Encrypt), and that the web server can prove control of private key XYZ, it declares the connection secure.
So what Certbot does:
Generates keypair XYZ
Automatically negotiates the domain validation process with Let's Encrypt (or any other ACME CA)
Downloads the signed certificate file from Let's Encrypt