No Email x.509 Certs?

https://github.com/certbot/certbot/issues/3981 maybe?

jmorahan, that was in January, surely fixed by now.

Trying this in certonly mode. Huh? “Page Not Found”? mail.quantum-equities.com wouldn’t have a webroot. But I need it in the SAM.

certbot certonly -d quantum-equities.com,www.quantum-equities.com,mail.quantum-equities.com

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Error while running apachectl configtest.

AH00526: Syntax error on line 13 of /etc/httpd/conf.d/bills-vhosts.conf:
SSLCertificateFile: file ‘/etc/pki/tls/certs/quantum-equities.com.crt’ does not exist or is empty

How would you like to authenticate with the ACME CA?

1: Apache Web Server plugin - Beta (apache) [Misconfigured]
2: Spin up a temporary webserver (standalone)
3: Place files in webroot directory (webroot)

Select the appropriate number [1-3] then [enter] (press ‘c’ to cancel): 3
Plugins selected: Authenticator webroot, Installer None
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for quantum-equities.com
http-01 challenge for www.quantum-equities.com
http-01 challenge for mail.quantum-equities.com

Select the webroot for quantum-equities.com:

1: Enter a new webroot

Press 1 [enter] to confirm the selection (press ‘c’ to cancel): 1
Input the webroot for quantum-equities.com: (Enter ‘c’ to cancel): /srv/QE

Select the webroot for www.quantum-equities.com:

1: Enter a new webroot
2: /srv/QE

Select the appropriate number [1-2] then [enter] (press ‘c’ to cancel): 2

Select the webroot for mail.quantum-equities.com:

1: Enter a new webroot
2: /srv/QE

Select the appropriate number [1-2] then [enter] (press ‘c’ to cancel): 2
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. mail.quantum-equities.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://mail.quantum-equities.com/.well-known/acme-challenge/DTaUuTuAPm9H-pbL5pnx-8M0SrKfdZXySksdgVxTk9M: "

Page Not Found - Quantum Equities, LLC</tit", www.quantum-equities.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.quantum-equities.com/.well-known/acme-challenge/kL9N2LlfdvbIGk7hdqz3M_m5XnkdwPNoQCr3AlV2zjk: " Page Not Found - Quantum Equities, LLC</tit", quantum-equities.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://quantum-equities.com/.well-known/acme-challenge/qRu75ddAPyfcHML5QyXxsz9hEP23Va3ye0OTc7_1qfo: " Page Not Found - Quantum Equities, LLC</tit"

IMPORTANT NOTES:

Ok now I think I’m down to it. I don’t have an initial cert, so I have to use certonly. certbot trips over itself for options 1 and 3 (Apache Web Server plugin - Beta (apache) [Misconfigured] and Place files in webroot directory [webroot] resp), so it has to be Option 2 (Spin up a temporary webserver [standalone]). But FIRST stop Apache.

certbot certonly -d quantum-equities.com,www.quantum-equitiesDOTcom,mail.quantum-equities.com

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Error while running apachectl configtest.

AH00526: Syntax error on line 13 of /etc/httpd/conf.d/bills-vhosts.conf:
SSLCertificateFile: file ‘/etc/pki/tls/certs/quantum-equitiesDOTcom.crt’ does not exist or is empty

How would you like to authenticate with the ACME CA?

1: Apache Web Server plugin - Beta (apache) [Misconfigured]
2: Spin up a temporary webserver (standalone)
3: Place files in webroot directory (webroot)

Select the appropriate number [1-3] then [enter] (press ‘c’ to cancel): 2
Plugins selected: Authenticator standalone, Installer None
Starting new HTTPS connection (1): acme-v01.api.letsencryptDOTorg
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for quantum-equitiesDOTcom
tls-sni-01 challenge for www.quantum-equitiesDOTcom
tls-sni-01 challenge for mail.quantum-equitiesDOTcom
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. www.quantum-equitiesDOTcom (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for tls-sni-01 challenge. Requested 0ef3bdd4580190baea718874d38caf60.8466075aed7b53b8b715e57d0a8a02d7.acme.invalid from 199.127.58.3:443. Received 1 certificate(s), first certificate had names “ctcouponDOTcom, mail.ctcouponDOTcom, www.ctcouponDOTcom”, quantum-equitiesDOTcom (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for tls-sni-01 challenge. Requested d6083418882a3288b96e8023c8c23f51.14882649067a53ec8a92c89346502c43.acme.invalid from 199.127.58.3:443. Received 1 certificate(s), first certificate had names “ctcoupon.com, mail.ctcoupon.com, www.ctcoupon.com”, mail.quantum-equities.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for tls-sni-01 challenge. Requested 06145c4fbe44719f606dc9f48aa6fe4d.188bb0357db557a2c0f865ca03752e96.acme.invalid from 199.127.58.3:443. Received 1 certificate(s), first certificate had names “ctcoupon.com, mail.ctcoupon.com, www.ctcoupon.com”

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: www.quantum-equities.com
    Type: unauthorized
    Detail: Incorrect validation certificate for tls-sni-01 challenge.
    Requested
    0ef3bdd4580190baea718874d38caf60.8466075aed7b53b8b715e57d0a8a02d7.acme.invalid
    from 199.127.58.3:443. Received 1 certificate(s), first certificate
    had names “ctcoupon.com, mail.ctcoupon.com, www.ctcoupon.com”

    Domain: quantum-equitiesDOTcom
    Type: unauthorized
    Detail: Incorrect validation certificate for tls-sni-01 challenge.
    Requested
    d6083418882a3288b96e8023c8c
    Domain: quantum-equitiesDOTcom
    Type: unauthorized
    Detail: Incorrect validation certificate for tls-sni-01 challenge.
    Requested
    d6083418882a3288b96e8023c8c23f51.14882649067a53ec8a92c89346502c43.acme.invalid
    from 199.127.58.3:443. Received 1 certificate(s), first certificate
    had names “ctcouponDOTcom, mail.ctcouponDOTcom, www.ctcouponDOTcom”

    Domain: mail.quantum-equitiesDOTcom
    Type: unauthorized
    Detail: Incorrect validation certificate for tls-sni-01 challenge.
    Requested
    06145c4fbe44719f606dc9f48aa6fe4d.188bb0357db557a2c0f865ca03752e96.acme.invalid
    from 199.127.58.3:443. Received 1 certificate(s), first certificate
    had names “ctcouponDOTcom, mail.ctcouponDOTcom, www.ctcouponDOTcom”

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A/AAAA record(s) for that domain
    contain(s) the right IP address.23f51.14882649067a53ec8a92c89346502c43.acme.invalid
    from 199.127.58.3:443. Received 1 certificate(s), first certificate
    had names “ctcoupon.com, mail.ctcoupon.com, www.ctcoupon.com”

    Domain: mail.quantum-equitiesDOTcom
    Type: unauthorized
    Detail: Incorrect validation certificate for tls-sni-01 challenge.
    Requested
    06145c4fbe44719f606dc9f48aa6fe4d.188bb0357db557a2c0f865ca03752e96.acme.invalid
    from 199.127.58.3:443. Received 1 certificate(s), first certificate
    had names “ctcoupon.com, mail.ctcoupon.com, www.ctcouponDOTcom”

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A/AAAA record(s) for that domain
    contain(s) the right IP address.

This seems alot like my registrar is returning a “ctcoupon” domain response to the cert query. This wouldn’t surprise me as they are a mess. But I’ve been waiting a week to get transferred away from them, and they are just not releasing me.

What can I do?

Hmm.

It looks like your host is directing traffic to their different customers based on TLS SNI information. If that’s true then the TLS-SNI-01 challenge (used by the --apache plugin, and the default for --standalone) won’t work. You can tell the --standalone plugin to use a different challenge by specifying --preferred-challenges http so that might be worth a try.

The webroot method might also work if you fix your Apache configuration first (by commenting out the broken SSL directives again). You would need to add a VirtualHost with a DocumentRoot for the mail subdomain (or add it as a ServerAlias to one of the existing ones).

1 Like

First attempt:

mail.quantum-equities.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Error while running apachectl configtest.

AH00526: Syntax error on line 14 of /etc/httpd/conf.d/bills-vhosts.conf:
SSLCertificateFile: file ‘/etc/pki/tls/certs/quantum-equities.com.crt’ does not exist or is empty

How would you like to authenticate with the ACME CA?

1: Apache Web Server plugin - Beta (apache) [Misconfigured]
2: Spin up a temporary webserver (standalone)
3: Place files in webroot directory (webroot)

Select the appropriate number [1-3] then [enter] (press ‘c’ to cancel): 2
Plugins selected: Authenticator standalone, Installer None
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for quantum-equities.com
http-01 challenge for www.quantum-equities.com
http-01 challenge for mail.quantum-equities.com
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. www.quantum-equities.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.quantum-equities.com/.well-known/acme-challenge/v0klws4ZWsgaULJMh0kdIAc24sgt_hMM6Jvk6Pt7mjw: "

Page Not Found - Quantum Equities, LLC</tit", mail.quantum-equities.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://mail.quantum-equities.com/.well-known/acme-challenge/8Tf1rFAc9iKEl93F7CEQua0nJ2DEPE1M2vF6whq-vhw: " Page Not Found - Quantum Equities, LLC</tit", quantum-equities.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://quantum-equities.com/.well-known/acme-challenge/e-7LS1n_DKPH_ebio0HtCpaprgg-t2AQiy6faPE3u8A: " Page Not Found - Quantum Equities, LLC</tit"

IMPORTANT NOTES:

############################################################
Second method (aka “I’m dead”):

certbot certonly --preferred-challenges http -d quantum-equities.com,www.quantum-equities.com,mail.quantum-equities.com

Saving debug log to /var/log/letsencrypt/letsencrypt.log

How would you like to authenticate with the ACME CA?

1: Apache Web Server plugin - Beta (apache)
2: Spin up a temporary webserver (standalone)
3: Place files in webroot directory (webroot)

Select the appropriate number [1-3] then [enter] (press ‘c’ to cancel): 3
Plugins selected: Authenticator webroot, Installer None
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
An unexpected error occurred:
There were too many requests of a given type :: Error creating new authz :: Too many failed authorizations recently.
Please see the logfiles in /var/log/letsencrypt for more details.

That is very strange indeed. You are definitely running certbot on the server, right? The only thing I can think of that might explain that, is if your host has some sort of reverse proxy that’s detecting when your Apache server isn’t running, and serving some sort of magic 404 page.

Even in that case, the webroot method should work… in theory (though there’s clearly some unknown variable in play here, so I’m hesitant to guarantee anything!) It’s not working right now because you’ve hit a rate limit, but that particular rate limit expires after an hour so you can try again soon. Or you could temporarily use the --staging server if you want to experiment while you wait.

Oh this is a little alarming. Can I just get my certs manually somehow?

Certainly am running only on the server (through SSH). There is nothing that could be snagging an 80 or 443 call:

listen

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
chronyd 691 chrony 1u IPv4 17245 0t0 UDP 127.0.0.1:323
chronyd 691 chrony 2u IPv6 17246 0t0 UDP [::1]:323
sshd 1079 root 3u IPv4 18837 0t0 TCP *:8734 (LISTEN)
sshd 1079 root 4u IPv4 18845 0t0 TCP *:22 (LISTEN)
master 1425 root 13u IPv4 19779 0t0 TCP 127.0.0.1:25 (LISTEN)
master 1425 root 17u IPv4 19782 0t0 TCP 127.0.0.1:587 (LISTEN)
sshd 25998 root 5u IPv4 1922867 0t0 TCP 10.1.1.30:22->192.168.111.2:8452 (ESTABLI
SHED)
sshd 26062 root 5u IPv4 1935090 0t0 TCP 10.1.1.30:22->192.168.111.2:9092 (ESTABLI
SHED)

Well, I can still connect to (www.)quantum-equities.com over both HTTP and HTTPS…

As for a “manual” method, certbot has a --manual option, and there’s https://zerossl.com/ - either way you would have to renew manually at least every 90 days, but if you’re switching hosts, you might have done so by then, and maybe you’ll have better luck setting up something more automated on your new host.

Ugh, --manual wants me to create a file on my old hoster. They’ve collapsed and I don’t have access to the files. This is why as I say, I’m changing hosting to my own VM. (and registrar due to broken DNSSEC, but that transfer is hung up)

This issue is stopping me from setting up my mail servers as I want them to use TLS (and the instructions I’m following require it), and I haven’t done this before so don’t know from SSL-TLS certificate to chain cert. If I knew what kind of files I’d end up with (.pem/.p12/.key/.cert) I’d have an idea how to fake it.

But maybe this is all hopeless and I just need to find another shared hoster, who will collapse like all the other cheapies have. I’ve spent over three weeks on this email service effort – how much time is reasonable? I really should be job-hunting

Ooooookay.... hang on.

Is your DNS still pointing at your old host, while you're running certbot on the new one?

That would explain all your problems!

If you have no access to the old host at all, the only option that will work is the DNS challenge, but even that might not work if you have broken DNSSEC. If you want to try it anyway, you can use --preferred-challenges dns with the --manual plugin, or select the "DNS verification" option on ZeroSSL.

EDIT: if you do this, remember to wait for the 1-hour rate limit to expire first!

Otherwise you'll just have to wait until after you've pointed the DNS at your new server.

When certbot works, you will get .pem files. I believe the same is true of ZeroSSL.

Yes. Ok no wonder. Mentioned that further up but admittedly it's a haystack.

Ok that helps. Is it one .pem for the three -d domains? (quantum-equities.com, www.quantum-equities.com, mail.quantum-equities.com) Or two, or three?

If so, do they contain? The Intermediate, private, and cert?

And for use with Postfix wouldn't I extract the .key and .crt? Also the Intermidiate? What should the intermediate be named? Would I concatenate the Intermediate to the .key?

You’ll get a set of 4 files for each certificate you obtain (ie. each time you successfully run certbot): a certificate (cert.pem), a private key (privkey.pem), an intermediate (chain.pem), and a combined file containing the certificate and intermediate (fullchain.pem). These files are valid for the set of domains you specified in the certbot command - so if you specified all 3 domains in one command, the certificate will cover all three. If you ran a separate certbot command for each domain, you’ll get 3 sets of files, one for each domain.

I’m not sure exactly how to configure postfix, but I’d guess you would use the privkey.pem and fullchain.pem. Maybe someone else here knows more about that.

Ah yes, the instructions are a bit muddled, but the intermediate and public cert seem to go together into the chain file.

I’ve been through a number of howto’s on postfix/dovecot and the others talk about a .key and .crt files, but .pem is Ok as long as I keep public and private straight.

(CentOS7) So I’ll rename privkey.pem to quantum-equities.com.key.pem and it goes in /etc/pki/tls/private, and I’ll rename fullchain.pem to quantum-equities.com.chain.pem and put it in /etc/pki/tls/certs. And the same with my other two domains’ certs.

Then I’ll reference these for both Apache and Postfix.

But it’s important to know whether these are encrypted? If so I must decrypt or will need to enter a password every time I check mail.

Thanks for your help J. With the answer to this last question I can press on.

Nope, they are not encrypted and don't require a password.

1 Like

Just be aware: certbot expects to find the files still in the same place when it tries to renew - it'll examine them to see if they need to be renewed yet. So it's better not to move or rename them. You can probably just refer to them directly in your apache / postfix configuration - /etc/letsencrypt/live/quantum-equities.com/fullchain.pem etc - those are symbolic links that refer to the actual files in /etc/letsencrypt/archive and are updated to point to the latest versions when the certificates are renewed. Or you can copy them if you really need them in a different location - use --deploy-hook to automate that if you need to.

Oh, yikes, I got to wondering how certbot would know where my renamed files are. (But I’d promised only one more question :j )

Yes I can point Apache and Postfix to the files in live, thanks.

1 Like

Hi,

I now have my websites resolving and DNATting properly. But certbot fails now in a new way! (Oh joy)

certbot run -d quantum-equities,www.quantum-equities.com,mail.quantum-equities.com

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
An unexpected error occurred:
The request message was malformed :: Error creating new authz :: DNS name does not have enough labels
Please see the logfiles in /var/log/letsencrypt for more details.

I can DNS resolve the first two, but I can’t ping mail.quantum-equities.com, even though it is set as my MX at GKG (my registrar).

Is this the cause of the error? Even though it is set as my MX, do I still have to set at registrar, resolution to my IP?

Also, what if my IP changes in the future? Wouldn’t this wreck the certs? How would I fix this?

Your command is malformed. The first in your series of domains is not, in fact, a domain name: "quantum-equities" :grinning:

Certs are not tied to IPs*, but rather domain names. Changing the IP these names resolve to will not break your certificates.

*Some CAs will issue for IP addresses, but this is not common and is not an option for Let's Encrypt.

WAT?! :relaxed:

Thanks. Now I have a different error: certificate had names "quantum.darkmatter.org"

This is an internal name for the server, and is quite different from the three public domain names this server serves, including quantum-equities.com. How do I rig it so I pass this test for the three different actual domain names?