Hello,
Maybe this is a silly question, but I'll just ask.
Is it possible somehow to get certificates from 2 separate AWS accounts and have them merged in an unique final certificate?
One of our customers has splitted their setup between 2 different AWS accounts and some software is not able to accept multiple pem certificates for each set of domains.
Thanks.
I'm not quite following your question. You can certainly have one certificate with multiple names, and if you're using DNS-01 authentication, say, you'd need to automate the process for each hostname, which is more involved if they're using different credentials but certainly possible with most ACME clients. If you're using HTTP-01 authentication, you'd need to have all the hostnames point to the same IP or do some other automation to ensure that each of the servers can respond to the challenge.
Basically, there are a lot of ways that one could configure to get Let's Encrypt certificates, with them getting more complicated as your configuration gets more complicated, but certainly it's all doable.
It might be helpful for you to peruse some of these documentation pages:
Hi,
Yeah, I get how it works, been using it for years like.. everywhere, both at work and for personal reasons, http, aws, cloudflare, ovh, etc.
My question is about the aws-route53 auth plugin and having 2 different aws accounts (2 different set of credentials). I know you can create a pem file just putting it all together, but that applies for the normal use with just one set of credentials.
I just wonder if you can get the certificate using a set of aws credentials (profile), another one using another set of aws credentials (a different profile) and then put it all together in a single pem file... which I don't think it would work because there are 2 different private keys involved.
So the use case would be certbot, in the same invocation, using first a set of credentials to verify one (or several) domain(s), then use another set of credentials to verify other set of domains, and finally generating the certificate with multiple SAN under the same private key.
Hope I've made myself clear enough now. And sorry if this is just not possible 
Yes, that's a much clearer question. I don't know if certbot's aws-route53 plugin supports multiple aws credentials. (Honestly, I could never get certbot's route53 plugin working on the same system I had aws-cli installed since they needed like different python versions or something like that, but it's not like I'd tried very hard to make it work.) It may be easier using some other ACME client that's designed for more complicated integrations than the "just install and go" that certbot tries to be, though you can probably make certbot work if you can write your own manual authorization script that uses the right credentials for the right domain. I've looked at a couple popular ACME clients and don't see one that obviously supports multiple AWS accounts, but I would have thought that it would be a normal thing. So maybe this is slightly harder than I initially thought.
Another option might be to delegate one account's domain's _acme-challenge name with a CNAME or NS to the other account's domain zone, and then you would only need one set of credentials, assuming that whomever needs these domains to be in different AWS accounts would be okay with that. Or even delegate it out of AWS entirely, to something like acme-dns or agnos. Not sure if that would make things simpler or more complicated for you. Like all of engineering, there's no perfect solution, there is just trying to understand what tradeoffs you're making.
And maybe someone else here has another suggestion for you.
What about using --manual mode? Someone manually places the TXT records for each domain to get one combined cert.
Could automate the TXT records using its manual-auth-hooks along the lines of what @petercooperjr mentioned.
I like Peter's suggestion of delegating the domain's _acme-challenge with CNAME the best - fwiw.
As far as I know (but someone certainly may correct me), cached valid authorizations are related to an ACME account. So as long as you're using the same ACME account, it wouldn't matter which AWS account was used to complete the challenge.
Does everything run on the same host?
That's correct. So the OP has two simple options to achieve their result:
Run Certbot/ACME-Client on an "office computer", using a single account, and complete the DNS-01 challenges. As @petercooperjr mentioned, if the given plugin does not support multiple AWS account credentials, this can be done either manually or by delegating the _acme-challenge record to another domain. The acme-dns project is a great candidate to handle this situation.
The OP was on the right track with their thoughts, and I think @Osiris was hinting at this solution but didn't state it, you can install a single ACME account credentials on both domains/machines. Machine 1 will request a cert for "Domain A", then complete a challenge, caching the valid authorization on LetsEncrypt for 30 days. Machine 2 can then request a cert for "Domain A, Domain B". Because both machines use the same account, Machine 2 will only be asked to complete a challenge for "Domain B" as Machine 1 already completed the challenge for "Domain A" and they both use the same acme-account.
The second strategy is simpler, but can cause issues on renewal due to the timing involved.
There are some other ways to get this done, which are all variations of the above, but they're more complex. The above methods have worked many times for me and are really the best two options IMHO.
If machine A gets a cert for domain A and then immediately deletes that cert...
Then machine B (using the same ACME account) can get a (SAN) cert for domains A+B.
But how will that be handled upon renewal?
What we haven't heard is: How will this SAN cert be used?
Adding that into the equation...
It seems, to me, like using CNAME delegation and DNS-01 authentication is the simplest solution.
One that can be implemented on a dedicated "cert management" system.
From there, the cert(s) can be deployed, or made available, to any number of systems.
Looking at the info from OP, the cert is to be used in a single piece of software without SNI support.
The cert is generated on a bastion host and then copied to other hosts to be used (for SMTPS & IMAPS respectively) with Qmail and Dovecot, and it's already working with multiple SAN on a sigle set of certificate files (1fullchain+1privkey). The problem is that Qmail has no support for multiple certificate files (Dovecot has), hence the problem.
Could be maybe done manually but there are a lot of hostnames, not really practical unfortunately. Also, manually doesn't allow unattended renewal later.
Another issue is, is that the Certbot Route53 plugin relies entirely on the Boto3 library for the handeling of the credentials. But maybe that's fine and perhaps Boto3 has the kind of support required? In an issue there is talk about something called "assume role". That specific thing is probably not the required thing, but maybe Boto3 has also support for multiple accounts, who knows?
See:
and also:
https://boto3.amazonaws.com/v1/documentation/api/latest/guide/credentials.html#assume-role-provider
Where that entire document is probably a good read and not the specific paragraph I'm linking to know (comes from the issue linked above).
Why would you need to use multiple certs/names for email?
If it is webmail based, you can just put it behind a proxy.
If it is SMTP based, any single name will do.
Because our customers use custom (their own domain's) mail.customername.tld hostnames for incoming mail/outgoing mail server hostnames in their desktop/mobile clients.
Yes, you can have an assumed role in your .aws/config/credentials file. Actually, any desired number of them. But the trick would be telling certbot (or any other client) something like "use profile THIS for domain1, domain2 and use profile THAT for domain3, domain4". I'm aware is not a normal use case though.
And that's all up to the Boto3 library I'm afraid. As I said, the credential handeling is managed by Boto3 and not by Certbot at all.
Is it too difficult to "teach" your customers to use "mail.YOURSERVICE.tld".
I mean, that's what Gmail does and they have millions of satisfied customers.
It really isn't "fooling" anyone.
The only people that would ever see that name (change) is the customer.
And they already know they outsource that service to you.
Well you know, sometimes business is also a lot about branding 
Anyway as this isn't showing an easy and permanent solution, we'll just do what you said using a private label (which was plan B from the beginning anyway, it will be just a shitstorm of complains the 1st day when people find out that their email client is not working anymore).
If all the domains point to the same server (even if the DNS is hosted in multiple AWS accounts), can you just use HTTP-01 authentication running certbot (or some other client) on the server itself?
On a tangent, if you have any windows server/machines you could use for certificate renewal then you can achieve this using https://certifytheweb.com ( the app I develop). A linux version is in the works but is not currently available.
You would configure your (single) managed certificate with multiple authorization configurations (how many depends on how many different domains/zones etc you are trying to configured credentials for). You would then optionally add one or more deployment tasks to push the certificate to the various servers and services that will use the certificates (via SSH /SFTP etc). You can also configure scripts for administrative tasks such as restarting remote services.
Perhaps not the most elegant solution, but what about just running Certbot twice?