[ENHANCEMENTS] Support use of certs on mapped volume

[focher]

Is your feature request related to a problem? Please describe. Yes (but not with Zoraxy). I'd like to be able to use the certificate that Zoraxy obtains through ACME on other servers but Zoraxy is not storing all of the pieces.

Describe the solution you'd like Currently, it appears that Zoraxy is only storing the pem and key files needed to support the certificate for its own reverse proxy purposes. Expected would be:

cert.pem: The server certificate itself. chain.pem: The intermediate certificates needed to validate your server cert. fullchain.pem: A combination of cert.pem and chain.pem. privkey.pem: Your private key.

However, Zoraxy is only storing _.domain.com.pem and _.domain.com.key which doesn't include the full chain or any intermediate certificates.

Describe alternatives you've considered I haven't explored alternatives yet, but am considering whether to move the entire process for registering and renewing certificates outside of Zoraxy and its ACME functionality.

Additional context Add any other context or screenshots about the feature request here.

[tobychui]

Hey @focher , currently we don't have a maintainer for the ACME module, so it is hard to say if this is possible or not.

But from what I learn from the previous maintainer for the ACME module, isn't ACME request only returns the lower part of the chain? The upper part of the chain should be securely stored inside the CA (e.g. Lets' Encrypt) and won't be released to us in anyway.

[focher]

Hey @focher , currently we don't have a maintainer for the ACME module, so it is hard to say if this is possible or not.

But from what I learn from the previous maintainer for the ACME module, isn't ACME request only returns the lower part of the chain? The upper part of the chain should be securely stored inside the CA (e.g. Lets' Encrypt) and won't be released to us in anyway.

Thanks for the reply. I actually stood up a dedicated Certbot container and used that to get a renewed certificate. This is what comes down. Strange that the ACME module doesn't store these same files.

privkey.pem : the private key for your certificate. fullchain.pem: the certificate file used in most server software. chain.pem : used for OCSP stapling in Nginx >=1.3.7. cert.pem : will break many server configurations, and should not be used without reading further documentation

[focher]

I changed the title to request consideration of supporting the use of certs from a mapped volume. This would allow the use of an external Certbot process to retrieve the certificates, store them in a common mapped volume, and then Zoraxy and other applications could utilize the certs this way.

[tobychui]

@focher Do certbot requires a specific path for storing certificates? The first thing that come to my mind is that maybe I can add a file change listener to the cert folder where your other script / bots can put certificate there.

[focher]

@focher Do certbot requires a specific path for storing certificates? The first thing that come to my mind is that maybe I can add a file change listener to the cert folder where your other script / bots can put certificate there.

Certbot does use a specific directory structure and naming convention, but I simply have that as a mapped volume into the container. The structure is below. If you incorporated a mapped volume that you monitored for the latest files, and then did whatever Zoraxy needs to support the certificates that would be absolutely terrific. I'd also point out that Certbot does support multiple certificates (as does Zoraxy's ACME) so the letsencrypt/archive and letsencrypt/live directories could have multiple subdirectories for each certificate.

/letsencrypt# tree . . ├── accounts │ └── acme-v02.api.letsencrypt.org │ └── directory │ └── 96412b4763e5b089894f2efd7afe3883 │ ├── meta.json │ ├── private_key.json │ └── regr.json ├── archive │ ├── domain.com │ │ ├── cert1.pem │ │ ├── chain1.pem │ │ ├── fullchain1.pem │ │ └── privkey1.pem ├── live │ ├── README │ ├── domain.com │ │ ├── README │ │ ├── cert.pem -> ../../archive/domain.com/cert1.pem │ │ ├── chain.pem -> ../../archive/domain.com/chain1.pem │ │ ├── fullchain.pem -> ../../archive/domain.com/fullchain1.pem │ │ └── privkey.pem -> ../../archive/domain.com/privkey1.pem ├── renewal │ ├── domain.com.conf └── renewal-hooks ├── deploy ├── post └── pre

[tobychui]

@zen8841 Maybe if you can take a look at this and see if you got any interest in working on this?

[shalafi99]

This looks like an interesting concept for evaluation. Since I use only 1 externally maintained cert with Zoraxy, for now I just copy it to the container with "docker cp" (/opt/zoraxy/config/conf/certs/) as a post-renewal task.

[zen8841]

@focher Hi. I'm the new maintainer of the ACME module. Sorry about the late reply. I test in my environment. _.domain.com.pem already contains the issuer CA cert. It's equal to the fullchain. The _.domain.com.pem have the structure

-----BEGIN CERTIFICATE-----
... The cert of your site
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
... The cert of the issuerCA (ex. lets encrypt)
-----END CERTIFICATE-----

The first certificate is equal to cert.pem. The second certificate is equal to chain.pem. Fullchain is combining cert and chain. I test with Let's Encrypt. The second certificate is R13(Subject: C=US, O=Let's Encrypt, CN=R13), the first certificate is signed by this CA. And R13 is signed by ISRG Root X1(Let's Encrypt rootCA). This CA is already trusted by the browser or system. Do not need to send again from zoraxy.

So, answer to your question

However, Zoraxy is only storing _.domain.com.pem and _.domain.com.key which doesn't include the full chain or any intermediate certificates.

_.domain.com.pem is the fullchain. The fullchain already includes cert and chain inside.

Or do you need the function to completely separate the cert?

Also

Currently, it appears that Zoraxy is only storing the pem and key files needed to support the certificate for its own reverse proxy purposes. Expected would be:

I think _.domain.com.pem and _.domain.com.key can be use by another app, like nginx or other.

[focher]

Hi. My request is that ACME store the Let's Encrypt certificates in the "standard" directory structure and naming convention. This would allow us to map the Let's Encrypt folder to a shared volume and use the certificates "as is". The issue that arises with the current naming and structure is that the certs become harder to use by other servers. Not sure what the driver that necessitated the current naming but just was wondering if the standard ones could be used instead of or in addition.

Alternatively, can it be supported to point to a mapped volume that is monitored for updated Let's Encrypt certs that are in the standard directory and file structure that then converts it to the naming and folder structure used by ACME / Zoraxy.