We have aws certificate for *.ourdomain.com and have acces to route53 zone ourdomain.com.
We now have usecase to generate a ssl certificate for app.ourdomain.com which must redirect to dns-entry for an external party. They seem to have cloudfront behind that dnsname.
How can i create a letsencrypt certificate for app.ourdomain.com ?(no access to external partys resources so cannot run certbot there)
By using the dns-01 challenge.
Correct me if I’m wrong @Osiris, but as long as the cert that’s actually installed on the machine serving app.ourdomain.com covers (at least) app.ourdomain.com then the wildcard certificate for *.ourdomain.com they already have will not pose a problem (unless the controllers of ourdomain.com were to act maliciously for some reason), correct?
@marcelvz
Welcome 
I agree with @Osiris. Be certain to ONLY GENERATE a certificate for app.ourdomain.com and do NOT install this certificate in your own space. The challenge will be (no pun intended) getting your ourdomain.com dns to respond to the app.ourdomain.com dns-01 challenge, which I think was your conundrum to begin with. Honestly though, can’t the controller of app.ourdomain.com just get the certificate issued? Handling the private key would be a nightmare if your two organizations are independent.
@Osiris
Thanks!
@ freessltools.com
wildcard we have for *.ourdomain.com is an AWS public certificate. Not usable outside AWS (and i assume also not usable in external party’s AWS)
What is exactly the challenge you mention; i am able to set TXT entry in our route53 for app.ourdomain.com. I have AWS credentials for route53 and also for ACM so creating a certificate via :
should be possible ?
If so, we can supply this certificate to external party which can import this in their AWS i assume ?
You are absolutely correct. You most likely won’t be able to automate the certificate renewal process unless route 53 offers a dns api to create and destroy txt records. You obviously can’t automate the installation of the certificates unless you’re given some kind of api to do so for the app.ourdomain.com server. I use dns-01 challenges with manual certificate installation for all of my own webservers (using my own web page acme client on my website). If you’re gonna do this correctly, you must:
There are a number of ways they can generate their private key and certificate signing request. Hopefully they have some type of control panel or other user-friendly mechanism to handle that and the eventual certificate installation. They could install an acme client only to generate the private key and certificate signing request and eventually install the certificate while you do the middle part of getting the certificate. Ask away if you’ve got questions.
By the way, the one line of code below when run on the app.ourdomain.com server will generate the private key in file “app.ourdomain.com.key” and the certificate signing request in file “app.ourdomain.com.csr”. They will be prompted for the basic info for app.ourdomain.com once they hit enter for the command. The only info they must get right is the common name (CN), which should be “app.ourdomain.com”. The rest (e.g. country, city, etc.) is actually discarded by the certificate authority since it can’t be verified anyhow. Just entering a dot “.” allows them to leave a field blank.
openssl req -new -newkey rsa:4096 -nodes -keyout app.ourdomain.com.key -out app.ourdomain.com.csr
This generates a new 4096-bit RSA private key and a corresponding certificate signing request (csr). The -nodes part is actually “no DES” meaning that it won’t try to encrypt the new private key with a passphrase that would only later need to be removed for the website to function correctly.
Hi @marcelvz
your setup is unclear.
What means
must redirect to dns-entry for an external party
Please share your domain name, so it's possible to understand that.
If app.ourdomain.com is simple a CNAME to that external party: Why do you want to create a certificate? If a certificate is required, that external party can (and should) create a certificate with app.ourdomain.com via normal http validation.
If it is a CNAME, you don't have access to that server, so you can't install the certificate. But that external party can - and it's their job to do that.
http validation -> http, so your existing https isn't relevant.
PS: That's
wrong. If that external party want to use the certificate, there must be an A-record (via CNAME) yourdomain -> their-IP. Then they are able to create and install the certificate.
So your action isn't required and it would block automation, because it's a manual action.
You don't want to do that every 60 days.
I agree @JuergenAuer. I pointed this out myself above. I figure if they want to generate the cert themselves they could, but having the controller of app.ourdomain.com create the certificate would make things much easier. The only (questionable) scenario I could see is if the controllers of ourdomain.com wanted to be able to monitor the traffic of app.ourdomain.com and thus would require their private key to do so.
Thanks for quick and very interresting replys !!
Our external party keeps asking for our certificate. But if we implement an entry in our route53 for app.ourdomain.com to their dnsname (which already is working. only not secure) they can get the certificate for app.ourdomain.com themselves ?
DO NOT GIVE THEM YOUR CERTIFICATE
That would require giving them your private key!
Bingo. Exactly. Create a CNAME from app.ourdomain.com to the IP address of their AWS as @JuergenAuer mentioned. They can then get a certificate via http-01 challenge as normal with automatic renewals. 
Yes, they can - and they must, it's their job.
I have the same - some customers point their subdomain database.customername.com via CNAME to my service server-daten.de, so they can use their database with their own subdomain name, not with the standard subdomain customername.server-daten.de.
Then I can create a certificate via http validation and install it.
Please don't use upper cases. And it's wrong. Such a service has the private and the public key of that certificate, that's the job of such a service.
Why would you ever give an external entity your private key? It's my understanding that app.ourdomain.com is controlled by separate people from ourdomain.com. Did I miss something?
Sorry about the uppercase. I saw it as a grave situation that warranted great emphasis.
Never knew you did this. Cool.
As you said earlier: the certificate needs to be installed somehow, somewhere. That would be the actual host to which the DNS resolves, i.e., in this case, the third party. They need access to the private key, otherwise TLS wouldn't work at all. As such, there is no security issue, as long as you generate a separate private key and don't share the key with other services.
Ok, so we have 2 options:
1: issue an certifcate ourselves for dedicated subdomain
2: let external party issue the certificate
With opion 1, auto-renewal is nogo i understand.
With option 2, can external party completely automate renewals ?
Do they not need aws credentials for our route-53 dns setup ?
(We currently have a CNAME record for app.ourdomain.com pointing to app.external.com)
Yes. That's their job if they have such a service. Today, such a service without encryption is a No-Go.
No, they have to use http validation. No dns access is required. It's a simple certificate with one (or two - www) domain names, no wildcard required.
Then your job is done (PS: Because with such a CNAME it's possible to create a certificate on the destination machine, so the private key is created there, doesn't leave that machine and is used to install / renew the certificate).
I think you missed something here:
The problem here isn't about the external party having their own private key. It's about the external party being given the private key to the original party's wildcard certificate. Hence my alarm.
My concurrence with @JuergenAuer's suggestion regarding the CNAME should have made my understanding of the situation quite clear. 
This:
was my whole point.
I was really hoping that you would actually acknowledge what I was trying to warn @marcelvz about in the message I wrote back to you regarding my use of capital letters.
@JuergenAuer and @Osiris
Don't get me wrong. I honestly believe you're both very talented and generous when it comes to helping people out here. I also feel at times like you're both on your own kind of team together that's not exactly on the same side that everybody should be on. We all make mistakes at times. I know I'm trying to learn a lot and have been from both of you. Please, please try if you would to understand what others helping are actually saying rather than making them feel undermined.
Ah, yes, that would be a bad thing indeed, give them a private key you're using yourself.
Might it be a problem (for autorenewal) if they let cloudfront/AWS-loadbalancers terminate the https (via imported certifaces in there AWS) and use http for there aplciation server(s) ?
May be. But that's their problem, not yours.
http validation works with http, not https, so it's possible to exclude /.well-known/acme-challenge. And it's possible to redirect to https / port 443 or to use a centralized solution.
There are tons of options they can use. And it's always the same: Today such a service must support https, so it's their job to find a solution.
Asking you about a certificate is the wrong way. That's no automation.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.