Support multiple certs in configuration

[alabiaga]

Currently amppackager has support for only 1 cert file. For a multi domain web property,

e.g.
example.org
subdomain.example.org
example.uk

Setting up amppackager would mean creating a config for every subdomain or TLD. The amppkg.toml should allow for setting the mapping of cert file to supported domains. An example of this is

CertFile = '.../global-cert.pem'
KeyFile =  '.../global-key.pem'
...

    [URLSet.Sign]
      CertFile = '.../cert-0.pem' # Override the global Certfile
      KeyFile = '.../privkey-0.pem' # Override the global KeyFile
      Domain = 'example.org'
       ...
    [URLSet.Sign]
      CertFile = '.../cert-1.pem' # Override the global Certfile
      KeyFile = '.../privkey-2.pem' # Override the global KeyFile
      Domain = 'example.uk'
      ...
    [URLSet.Sign]
      # Use the global Certfile and KeyFile
      Domain = 'example.org'
      ...

[alabiaga]

cc\ @twifkak Let me know if this is what you had in mind in our discussions.

[twifkak]

Yes, this is what I had in mind! I'm guessing for the initial implementation of this feature, it wouldn't have ACME support. @banaag is landing #349 which adds ACME support, but scaling that to handle N certificates would require a significant restructuring of the code.

[banaag]

Definitely possible to support this feature with ACME but as @twifkak mentioned above, it will require significant amount of changes.

[ithinkihaveacat]

Are multiple certificates absolutely necessary? I'm not sure if this will apply in this case, but a cert can typically cover multiple domains, and even span different TLDs. (And I think amppackager supports this.) The same Google cert is used for google.com, google.nl and android.com, for example.

Different organizations should perhaps not share the same amppackager instance anyway, to keep their private keys as far away from each other as possible.

[alabiaga]

@ithinkihaveacat Thanks for sharing Michael, that is a good point. So there is a lack of context in the filing of this issue but basically a publisher can have different certificates for multi TLDs and subdomains that it owns and distributed through different CDNs. I am not familiar with multi certificate and CDN strategies or why this is the case but we are basically trying to cover that scenario.

[alabiaga]

@cpapazian Is #374 still a blocker? We noticed your orgs web properties has a cert issued by DigiCert. Are there multiple certs being used from DigiCert to cover different domains or just one to rule them all? Thanks

[cpapazian]

we use one certificate for all country subdomains and TLDs. we haven't acquired the certificate yet, but plan on using the same configuration that we use for our web properties.

…

On Thu, Nov 21, 2019 at 6:05 PM Aaron Labiaga ***@***.***> wrote: @cpapazian <https://github.com/cpapazian> Is #374 <#374> still a blocker? We noticed your orgs web properties has a cert issued by DigiCert. Are there multiple certs being used from DigiCert to cover different domains or just one to rule them all? Thanks — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#363?email_source=notifications&email_token=AAOZQYAPVP23K7F756F53JLQU446ZA5CNFSM4JG4ZUWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE4I4PY#issuecomment-557354559>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOZQYEAMFQPX22FLFPOVP3QU446ZANCNFSM4JG4ZUWA> .

[twifkak]

Note that a fix is in #374, pending my review. Just got back from a 2-week trip to Singapore/Bali; pardon the delay.

[twifkak]

Also note that a workaround, in the interim, is to run different amppkg instances with different configs.

[alabiaga]

@twifkak No problem, note that I still need to make changes to this, given the changes from #361. I will note it on the PR. Thanks

…

On Thu, Dec 5, 2019 at 2:53 PM Devin Mullins ***@***.***> wrote: Note that a fix is in #374 <#374>, pending my review. Just got back from a 2-week trip to Singapore/Bali; pardon the delay. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#363?email_source=notifications&email_token=AADYUUECHUGNNBNSFCF4JFDQXGA5FA5CNFSM4JG4ZUWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGCNTVA#issuecomment-562354644>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADYUUE3ONDTLJJL7NX7BWLQXGA5FANCNFSM4JG4ZUWA> .