There is command in ACS, UploadCustomCertificateCmd, which can receive ssl cert, key can chain as input. Maybe can share some code?
> -----Original Message----- > From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com] > Sent: Tuesday, October 08, 2013 1:54 PM > To: dev@cloudstack.apache.org > Subject: Re: [New Feature FS] SSL Offload Support for Cloudstack > > The API should do input validation on the SSL cert, key and chain. > Getting those three pieces of info is usually difficult for most people to get > right as they don't really know what those three things are. There's about a > 80% chance most calls will fail. If you rely on the provider it will > probably just > give back some general failure message that we won't be able to map back to > the user as useful information. > > I would implement the cert management as a separate CertificateService. > > Darren > > On Tue, Oct 8, 2013 at 1:31 PM, Syed Ahmed <syed1.mush...@gmail.com> > wrote: > > A question about implementation. I was looking at other commands and > > the > > execute() method for each of the other commands seem to call a service > > ( _lbservice for example ) which takes care of updating the DB and > > calling the resource layer. Should the Certificate management be > > implemented as a service or is there something else that I can use? An > > example would be immensely helpful. > > > > Thanks > > -Syed > > > > > > > > On Tue 08 Oct 2013 03:22:14 PM EDT, Syed Ahmed wrote: > >> > >> Thanks for the feedback guys. Really appreciate it. > >> > >> 1) Changing the name to SSL Termination. > >> > >> I don't have a problem with that. I was looking at Netscaler all the > >> time and they call it SSL offloading. But I agree that termination is > >> a more general term. > >> I have changed the name. The new page is at > >> > >> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Terminatio > >> n+Support > >> > >> > >> 2) Specify the protocol type. > >> > >> Currently the protocol type of a loadbalncer gets set by checking the > >> source and destination port ( see getNetScalerProtocol() in > >> NetscalerResouce.java ) . So, we should change that and add another > >> optional field in the createLoadBalancerRule for protocol. > >> > >> 3) Certificate chain as a seperate parameter. > >> > >> Again, I was looking at Netscaler as an example but separating the > >> chain and certificate makes sense. I have updated the document > >> accordingly. > >> > >> I was assuming that the certificate parsing/validation would be done > >> by the device and we would just pass the certficate data as-is. But > >> if we are adding chains separately, we should have the ability to > >> parse and combine the chain and certificate for some devices as you > mentioned. > >> > >> Thanks > >> -Syed > >> > >> > >> On Tue 08 Oct 2013 02:49:52 PM EDT, Chip Childers wrote: > >>> > >>> > >>> On Tue, Oct 08, 2013 at 11:41:42AM -0700, Darren Shepherd wrote: > >>>> > >>>> > >>>> Technicality here, can we call the functionality SSL termination? > >>>> While technically we are "offloading" ssl from the VM, offloading > >>>> typically carries a connotation that its being done in hardware. So > >>>> we are really talking about SSL termination. > >>> > >>> > >>> > >>> +1 - completely agree. There's certainly the possibility of an > >>> *implementation* being true offloading, but I'd generalize to > >>> "termination" to account for a non-hardware offload of the crypto > >>> processing. > >>> > >>>> > >>>> > >>>> Couple comments. I wouldn't want to assume anything about SSL > based > >>>> on port numbers. So instead specify the protocol > >>>> (http/https/ssl/tcp) for the front and back side of the load > >>>> balancer. Additionally, I'd prefer the chain not be in the cert. > >>>> When configuring some backends you need the cert and chain > >>>> separate. It would be easier if they were stored that way. > >>>> Otherwise you have to do logic of parsing all the certs in the "keystore" > and look for the one that matches the key. > >>> > >>> > >>> > >>> Also +1 to this. Cert chains may be optional, certainly, but should > >>> actually be separate from the actual cert in the configuration. The > >>> implementation may need to combine them into one document, but > >>> that's implementation specific. > >>> > >>>> > >>>> > >>>> Otherwise, awesome feature. I'll tell you, from an impl > >>>> perspective, parsing and validating the SSL certs is a pain. I can > >>>> probably find some java code to help out here on this as I've done > >>>> this before in the past. > >>> > >>> > >>> > >>> Yes, this is a sorely needed feature. I'm happy to see this be added > >>> to the Netscaler plugin, and await a time when HA proxy has a stable > >>> release that includes SSL term. > >>> > >>>> > >>>> > >>>> Darren > >>>> > >>>> On Tue, Oct 8, 2013 at 11:14 AM, Syed Ahmed <sah...@cloudops.com> > >>>> wrote: > >>>>> > >>>>> > >>>>> Hi, > >>>>> > >>>>> I have been working on adding SSL offload functionality to > >>>>> cloudstack and make it work for Netscaler. I have an initial > >>>>> design documented at > >>>>> > >>>>> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offload > >>>>> ing+Support > >>>>> > >>>>> and I would really love your feedback. The bug for this is > >>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-4821 . > >>>>> > >>>>> Thanks, > >>>>> -Syed > >>>>> > >>>>> > >>>> > >>>> > >>> > >> > >> > > > >
