BouncyCastle, its already in ACS. Off list I'll send you some sample code on how to validate this stuff.
Darren On Tue, Oct 8, 2013 at 1:58 PM, Syed Ahmed <sah...@cloudops.com> wrote: > Thanks Darren for your reply. > > Do you happen to have any info on a library that I can use for certificate > validation? > > Thanks, > -Syed > > > > On Tue 08 Oct 2013 04:53:40 PM EDT, Darren Shepherd wrote: >> >> 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+Termination+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+Offloading+Support >>>>>>> >>>>>>> and I would really love your feedback. The bug for this is >>>>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-4821 . >>>>>>> >>>>>>> Thanks, >>>>>>> -Syed >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> > >
