'cerbot certificates' does not list existing certs, manually installed

Help
1

I’ve setup my LE data dir with symlinks another dir,

	ls -al /etc/letsencrypt/
		total 24K
		drwxr-xr-x   2 root root 4.0K Jul 18 09:54 ./
		drwxr-xr-x 228 root root  20K Jul 17 21:23 ../
		lrwxrwxrwx   1 root root   35 Jul 18 08:25 accounts -> /sec/letsencrypt/accounts/
		lrwxrwxrwx   1 root root   31 Jul 18 08:41 live -> /sec/letsencrypt/live/
		lrwxrwxrwx   1 root root   40 Jul 18 08:41 renewal-hooks -> /sec/letsencrypt/renewal-hooks/

Running manual certbot, I’ve created staging certs, named with timestamps,

	tree /sec/letsencrypt/data/certs/example.com
		/sec/letsencrypt/data/certs/example.com
		├── cert.ec.1531934048.crt.pem
		├── chain.ec.1531934048.crt.pem
	    └── fullchain.ec.1531934048.crt.pem

and generated generic links,

	tree /etc/letsencrypt/live
		/etc/letsencrypt/live
		└── example.com
		    ├── cert.ec.crt.pem -> /sec/letsencrypt/data/certs/example.com/cert.ec.1531932039.crt.pem
		    ├── chain.ec.crt.pem -> /sec/letsencrypt/data/certs/example.com/chain.ec.1531932039.crt.pem
		    ├── fullchain.ec.crt.pem -> /sec/letsencrypt/data/certs/example.com/fullchain.ec.1531932039.crt.pem
	1531932039.crt.pem
		    └── trusted.crt.pem -> /sec/letsencrypt/data/certs/trusted.crt.pem

if I attempt to view the existing certs, none are found

certbot -vvv certificates
	Root logging level set at -10
	Saving debug log to /var/log/letsencrypt/letsencrypt.log

	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	No certs found.
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

cat /var/log/letsencrypt/letsencrypt.log
	2018-07-18 11:09:52,382:DEBUG:certbot.main:certbot version: 0.26.0
	2018-07-18 11:09:52,384:DEBUG:certbot.main:Arguments: ['-vvv']
	2018-07-18 11:09:52,385:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
	2018-07-18 11:09:52,405:DEBUG:certbot.log:Root logging level set at -10
	2018-07-18 11:09:52,406:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log

But, I can work with existing certs, e.g., to revoke an existing cert,

certbot -vvv revoke --staging --cert-path /etc/letsencrypt/live/example.com/cert.ec.crt.pem
	Root logging level set at -10
	Saving debug log to /var/log/letsencrypt/letsencrypt.log
	Revoking /etc/letsencrypt/live/example.com/cert.ec.crt.pem using Account Key
	Sending GET request to https://acme-staging-v02.api.letsencrypt.org/directory.
	Starting new HTTPS connection (1): acme-staging-v02.api.letsencrypt.org:443
	https://acme-staging-v02.api.letsencrypt.org:443 "GET /directory HTTP/1.1" 200 724
	Received response:
	HTTP 200
	Server: nginx
	Content-Type: application/json
	Content-Length: 724
	X-Frame-Options: DENY
	Strict-Transport-Security: max-age=604800
	Expires: Wed, 18 Jul 2018 14:10:57 GMT
	Cache-Control: max-age=0, no-cache, no-store
	Pragma: no-cache
	Date: Wed, 18 Jul 2018 14:10:57 GMT
	Connection: keep-alive

	{
	  "6u2RSZIrL9M": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417",
	  "keyChange": "https://acme-staging-v02.api.letsencrypt.org/acme/key-change",
	  "meta": {
	    "caaIdentities": [
	      "letsencrypt.org"
	    ],
	    "termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf",
	    "website": "https://letsencrypt.org/docs/staging-environment/"
	  },
	  "newAccount": "https://acme-staging-v02.api.letsencrypt.org/acme/new-acct",
	  "newNonce": "https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce",
	  "newOrder": "https://acme-staging-v02.api.letsencrypt.org/acme/new-order",
	  "revokeCert": "https://acme-staging-v02.api.letsencrypt.org/acme/revoke-cert"
	}
	Reason code for revocation: 0
	Requesting fresh nonce
	Sending HEAD request to https://acme-staging-v02.api.letsencrypt.org/acme/revoke-cert.
	https://acme-staging-v02.api.letsencrypt.org:443 "HEAD /acme/revoke-cert HTTP/1.1" 405 0
	Received response:
	HTTP 405
	Server: nginx
	Content-Type: application/problem+json
	Content-Length: 103
	Allow: POST
	Replay-Nonce: Kvj...J6o
	Expires: Wed, 18 Jul 2018 14:10:57 GMT
	Cache-Control: max-age=0, no-cache, no-store
	Pragma: no-cache
	Date: Wed, 18 Jul 2018 14:10:57 GMT
	Connection: keep-alive


	Storing nonce: Kvj...J6o
	JWS payload:
	b'{\n  "resource": "revoke-cert",\n  "certificate": "MII...kxg",\n  "reason": 0\n}'
	Sending POST request to https://acme-staging-v02.api.letsencrypt.org/acme/revoke-cert:
	{
	  "protected": "eyJ...Yvg",
	  "payload": "ewo...Cn0"
	}
	https://acme-staging-v02.api.letsencrypt.org:443 "POST /acme/revoke-cert HTTP/1.1" 200 0
	Received response:
	HTTP 200
	Server: nginx
	Content-Length: 0
	Boulder-Requester: 283299
	Replay-Nonce: zth...eY0
	X-Frame-Options: DENY
	Strict-Transport-Security: max-age=604800
	Expires: Wed, 18 Jul 2018 14:10:57 GMT
	Cache-Control: max-age=0, no-cache, no-store
	Pragma: no-cache
	Date: Wed, 18 Jul 2018 14:10:57 GMT
	Connection: keep-alive


	Storing nonce: zth...eY0

	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	Would you like to delete the cert(s) you just revoked?
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	(Y)es (recommended)/(N)o: N
	Reporting to user: Not deleting revoked certs.

	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	Congratulations! You have successfully revoked the certificate that was located
	at /etc/letsencrypt/live/example.com/cert.ec.crt.pem

	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

	IMPORTANT NOTES:
	 - Not deleting revoked certs.

What’s needed to list existing certs, using ‘certbot certificates’?

2

As far as I know, certbot uses the renewal configuration files in /etc/letsencrypt/renewal/ for the certificates feature.

3

@Osiris

If that’s the case, then what’s needed to get that directory created & populated?

/usr/bin/tree /etc/letsencrypt/
  /etc/letsencrypt/
  ├── accounts -> /usr/local/etc/letsencrypt/accounts
  ├── live -> /usr/local/etc/letsencrypt/live
  └── renewal-hooks -> /usr/local/etc/letsencrypt/renewal-hooks
4

I think that’s a little bit complicated, as certbot fills those configuration files corresponding with the input to certbot when creating the certificates.

Why do you use certbot anyway when you’re just using a fraction of its features? I don’t think this is the proper method of using this particular client. It only makes things very difficult. You’re making it very difficult for yourself.

If you’re just manually generating certificates and want to renew them, why not using a simpel bash client like acme.sh?

5

Even acme.sh has its own configuration file structure, roughly equivalent to Certbot’s.

6

Perhaps, but I think @hal703 possibly uses the --csr option, because it seems he’s using elliptic curve keys, which aren’t possible with the current version of the official certbot branch without the --csr option. And with the --csr option, you’re not getting the renewal configuration file as far as I remember.

acme.sh can use ECDSA keys from “stock” acme.sh. No need to do any extra-ordinary stuff. I believe it would be a better “match” with the non-standard certbot methods @hal703 seems to require.

2 Likes
7

... If you’re just manually generating certificates and want to renew them,

You're assuming, but incorrectly.

I've been using it just fine for quite awhile, albeit in tls-sni mode. It has met my needs to date -- both technically, and having some support behind it.

which aren’t possible with the current version of the official certbot branch without the --csr option.

I can't say I understand what point you're making.

EC certs are supported by the released client using one of its documented options.

And, I specify my own csr for a number of reasons; using it "for EC" certainly is nothing 'extra-ordinary'.

I'm simply asking here, in this thread, about specific behavior, using a simple example to pose the issue.

8

Osiris is correct that if you’re using Certbot with --csr, certbot certificates will not work. This is because certbot certificates currently only lists information about certificates being “managed” by Certbot. When you use --csr, Certbot cannot add or remove domains, install the cert to your webserver, request extensions like must staple, etc. While you could make it work by recreating Certbot’s directory layout, this layout is not documented and may change in the future so I’d encourage you not to try and do that.

certbot certificates lists the domains in the cert, expiration date, path to the certificate, and path to the private key. If you are using certbot certonly --csr, you should have the two paths and you’re probably comfortable enough with openssl to generate a CSR so you can obtain the domains and expiration date with openssl x509 -in /path/to/cert -noout -text.

9

@bmw clear, thx.

I recall some mention of “if you’re using Certbot with --csr, certbot certificates will not work”, but haven’t found it officially yet.

yep, I can work around just about all of what’s “missing” with DIY scripts; that’s what I’ve been doing in general with tls-sni mode for the past long while.

now that’s gone away, switching over to dns-01 challenges, I’m just taking a (re)look at all functionality “in” certbot. Sure, I’d like to have it all working for my needs. Not yet, seems. Will get there eventually.

10

Which client and version do you refer to? As far as I know, certbot currently, as of 0.26.1, doesn't natively support ECDSA keys yet, only with "hacks" like using your own CSR with the --csr option. Which disables most of the other functions of certbot like @bmw explained.

11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.