![]() ![]() What's the upside of storing it in the hosting DB?. I understand and agree with the complaint that it seems less secure. The spec doesn't touch on how a consumer would get a copy of the certificate from the provider.ĭ) The spec equivocates a bit on whether to store the key+cert in the hosting DB. uploading a cert to the hosting DB auto-generating a cert with a CA's API), and there will be several ways to consume a cert (e.g. My impression is that this should be done on a per-site basis.ī) How should SSL interact with site aliases? Is it appropriate to provision certificates for aliases?Ĭ) It sounds like there will be several ways to produce a cert (e.g. auto-generate a self-signed cert use an API from an SSL vendor ask clients to upload a cert), she could make that decision for an individual site, for a platform, or for all sites hosted in Aegir. When an Aegir admin chooses a way to provide certificates (e.g. A few comments:Ī) One thing that wasn't explicit in the spec was the grain of the SSL policy. I like the functionality that's described in the spec. In short, I do not want to discard the idea of working with pound, ng, relayd or any load balancing solution for SSL support: I'm just saying it should not be the first objective and we have some work to do regardless of what will use the actual SSL cert. There 's also no intervention required from the user if we can implement a communication layer with an existing SSL provider API (like gandi, but they don't have it yet), or it will require minimal intervention from the user ("copy-paste the certificate from your provider here") in the worst case.Īs for DNS: it will (as of 0.4) be Aegir's job to take care of DNS, so that's something we'll have to take care of if we're going to play with load balancers. In my spec, the only thing that actually relates to Apache is step 3: configuring vhosts, which will also need to be done for pound (unless you use wildcards).Ībout manual intervention: my spec is designed so there is no required manual intervention (assuming password-less certificates) from the administrator. This needs to be managed in the frontend and the backend. It doesn't change anything in my proposal: you still need to manage the SSL certificates, per domain (so per site). So I know about pound and SSL load balancers. In this scenario Pound works as a transparent SSL layer without any change in the backend config. (DNS change involved - but this is not Aegir job, anyway). You just need unique IP per SSL enabled domain where Pound can listen on port 443. To clarify something: when using Pound as a front-end SSL, you don't need to change/add separate IP/port for back-end in Aegir/Apache. It would be cool to have a new SSL toy in the Aegir, but let's remember about all manual work you can't avoid here. In any case: enabling SSL can't be fully automated - you have to create private key and CSR request and figure out how to bundle it all together depending on SSL cert provider (intermediate certs etc.) OK, I know we need something for Apache based SSL in Aegir, but think for a moment you can make your life easier :) ![]() As a bonus - if you really can't live without Apache, you can keep the Apache smaller, since you don't need to load SSL module in this setup. ![]()
3 Comments
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |