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?
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.
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:
Have the controller of app.ourdomain.com generate their own private key and certificate signing request.
Have them hand you their certificate signing request.
Use an acme client of your own with their certificate signing request and create the necessary dns txt records (either automatically via api or manually with the acme client paused).
Hand them back the newly-generated certificate to install.
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.
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.
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.
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.
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.
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 ?
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.
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).
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.