How to extract the csr from my current let’s encrypt configured server.
The CSR? Not the certificate? What do you want it for?
It depends on the client. It may not have been saved.
A new CSR can always be generated from the private key, though.
1 Like
I do believe Certbot saves the CSR by default, if I’m not mistaken. I don’t know the directory off the top of my head, though.
If you used Certbot, it’s archived in /etc/letsencrypt/csr. I would agree that there are not that many use cases for which a Certbot-generated CSR is very useful. (Note for example that currently if you renew with certbot renew, the new certificate will have a new subject key, which will no longer correspond to the key in the previous CSR.)
If you could let me know how to generate the csr from The private key that would also be useful.
I see a bunch of files here , about 9 sequentially numbered ‘0000_csr-certbot.pem’ to ‘0009_csr-certbot.pem’, are they a chain, or only the latest file is valid
A third party service we use wanted to host their service on our community.example.com subdomain. they are asking for the csr chain or pfx file for that particular subdomain to be configured in their IIS/Load balancer. Is it secure to share this since we trust the party
So, they’re planning to use their own independent web server that will be reachable via community.example.com? And you don’t have an existing Let’s Encrypt certificate that covers that domain name, because you don’t currently use that name on your own site? Did I understand that correctly?
That's probably not what they meant. I suspect they meant to ask for the certificate chain, especially given that they asked for a PFX as an alternative, which does not store CSRs, but rather certificates and private keys.
Either way, I'd like to hear a better explanation of what's happening here before recommending any particular course of action.
2 Likes
No your private keys are yours and should not be shared.
The only reason why they may need a private key and certificate would be to decrypt the traffic for inspection.
While this may seem like a good idea it is not.
If you are offering your service to multiple clients the one client with your key may be able to decrypt all traffic (not just theirs) going to your server
This is what I am assuming is happening
Your Web Server <- 3rd Party IIS Server <- 3rd Party Clients (desktops)
What they should do in my opinion is provide you with a CSR which you can validate with certbot and then you can send them a valid certificate to install on their IIS server. As they will most likely not be able to complete the required challenges you will need to do that for them.
Please review an article I wrote for something similar: https://www.linkedin.com/in/andrei-hawke-b9140a14/detail/recent-activity/posts/
A) You do not need to send them the PFX. If they use the certreq command the private key will be automatically stored in the windows store
B) They can then import the certificate you provide for them
C) They will be able to decrypt traffic from their clients to their IIS server. They will not be able to decrypt the traffic from their IIS server to your web server.
But do not ever share your private keys with other parties.
Andrei
Because of how Let’s Encrypt works, if you put the other steps in place to allow the supplier to run a Web site on community.example.com they will be able to use Let’s Encrypt to get and renew certificates because they will be able to prove “control” over that exact name.
The only additional caveat is that your organisation must not have a policy forbidding Let’s Encrypt from issuing, which would be expressed using a CAA record. If you’ve never heard of CAA records then it’s all fine.
With this approach nobody needs to manually send CSRs or PFXs anywhere, and private keys stay where they should be.
However, you might still have a problem if your supplier is not familiar with Let’s Encrypt and doesn’t want to learn how to do this! (This is more of a “won’t” than a “can’t” problem, though.)
(or if the supplier has an automated setup exclusively based on a different certificate authority)
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.