When running or renewing with --no-bundle
, the generated [domain].crt
file contains the server (or wildcard in this case) certificate followed by the issuer certificate.
I'd expect there to be only one certificate in the [domain].crt
file.
root@server:/opt/lego# docker run --rm goacme/lego:latest -v
lego version v3.0.2 linux/amd64
root@server:/opt/lego# docker run --rm goacme/lego:latest renew -h
[...]
--no-bundle Do not create a certificate bundle by adding the issuers certificate to the new certificate.
[...]
root@server:/opt/lego# docker run --rm \
--env-file /opt/lego/.env \
-v /opt/lego:/.lego \
goacme/lego:latest \
--dns="azure" \
--key-type="ec256" \
--email="me@my_domain.com" \
--domains="*.rd.my_domain.com" \
--accept-tos \
renew --no-bundle --days 120
2019/09/07 [INFO] [*.rd.my_domain.com] acme: Trying renewal with 2158 hours remaining
2019/09/07 [INFO] [*.rd.my_domain.com] acme: Obtaining SAN certificate
2019/09/07 [INFO] [*.rd.my_domain.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/237346520
2019/09/07 [INFO] [*.rd.my_domain.com] acme: authorization already valid; skipping challenge
2019/09/07 [INFO] [*.rd.my_domain.com] acme: Validations succeeded; requesting certificates
2019/09/07 [INFO] [*.rd.my_domain.com] Server responded with a certificate.
root@server:/opt/lego# cat certificates/_.rd.my_domain.com.crt | grep "BEGIN CERTIFICATE" | wc -l
2
And if you diff the second cert with the issuer.crt, they're identical.
This bit us too -- looks like --no-bundle doesn't currently work.
I did implement a workaround in the shell script to distribute the certificates with this kind of simple trick:
openssl x509 -in /path/to/example.com.crt -out /path/to/example.com-no-bundle.crt
As the openssl x509 command only takes the first certificate out of the input file, and without any other options like the usually used '-noout -text', it just outputs the PEM again. With -out it creates /path/to/example.com-no-bundle.crt with just the server certificate.
I may confirm the issue is still there in latest version.
Most helpful comment
This bit us too -- looks like --no-bundle doesn't currently work.