On Wed, Apr 4, 2018 at 10:36 AM, Rafael Weingärtner < rafaelweingart...@gmail.com> wrote:
> So, you need a certificate that is signed by the CA that is used by the VPN > service. Is that it? > > Correct, a self signed "server certificate" against CA, to be installed directly on VR. > > It has been a while that I do not configure these VPN systems; do you need > access to the private key of the CA? Or, does the program simply validate > the user (VPN client) certificate to see if it is issued by a specific CA? > I believe it also needs the public key of the user to execute the handshake > and create the connection. > > > No, end user only needs to have Root CA at hand, to *trust* it. Both the "Server Certificate" and "Server Private Key" are sensitive information and only exist on VR. User then can go ahead and install the Root CA on their local machine and open up VPN connection with strongSwan client of the correspondning OS they're on import the Root CA, and their credential (EAP on VPN side), and that's it. > > > On Wed, Apr 4, 2018 at 11:22 AM, Khosrow Moossavi <kmooss...@cloudops.com> > wrote: > > > Rafael, > > > > We cannot use SshKeyPair functionality because the proposed VPN > > implementation > > does need a signed certificate and not a ssh key pair. The process is as > > follow: > > > > 1) generate root CA (if doesn't exist) > > 2) generate bunch of intermediate steps (config urls, CRLs, role name, > ...) > > [I'm not going > > in detail now, here, for simplicity] > > 3) self sign a certificate against the root CA (regenerate every time > start > > VPN command > > executed) > > > > This will produce: > > > > 1) Root CA cert (one per domain in cloudstack) > > 2) Server cert (one per VR) > > 3) Server private key (one per VR) > > > > Then all the above will be pushed to the said VR we want to start VPN on, > > and start > > ipsec service on it (with extra configuration - which will be available > in > > codebase) and > > finally present Root CA for user to download and install on their local > > machine to be > > able to "trust" VR they are VPNing to. > > > > > > > > On Wed, Apr 4, 2018 at 6:19 AM, Rafael Weingärtner < > > rafaelweingart...@gmail.com> wrote: > > > > > Khosrow thanks for the interesting feature. You mention two possible > > > methods to manage certificates; one using the CA framework, and other > > using > > > third party such as Vault and Let’s Encrypt. > > > > > > Have you considered using the sshKeyPair API methods (is it part of the > > CA > > > framework?)? I mean, users already can generate key pairs via ACS, and > > then > > > they are presented with the private key. You could simply list these > > > certificates for the user when they want to configure a new certificate > > for > > > a VPN or generate one in runtime using this feature. Reading your > feature > > > proposal I did not understand how you are binding certificated with a > VPN > > > (are you always generating new ones and simply returning the private > key > > to > > > users?). > > > > > > Moreover, as the sshKeyPair methods, I do believe you should only > return > > > the private key once. Therefore, you should not store it in ACS. > > > > > > On Mon, Apr 2, 2018 at 4:36 PM, Khosrow Moossavi < > kmooss...@cloudops.com > > > > > > wrote: > > > > > > > Hi Community > > > > > > > > I want to open up a discussion around the new Remote Access VPN > > > > implementation on VRs. Currently > > > > we have only L2TP implementation, which lacks different features > (such > > as > > > > verbos logging), so we > > > > decided to start developing new implementation based on IKEv2 (on top > > of > > > > the existing strongSwan). > > > > > > > > We have this feature working locally for over a week now, and seems > to > > be > > > > ready for opening up a > > > > PR on official repo. But before doing so we agreed to open up a > > > discussion > > > > here first. > > > > > > > > The current implementation we use EAP + Public Key for > authentication, > > so > > > > we need to have a PKI > > > > Engine somewhere. Rather than start re-inventing the wheel (and start > > > > extending the current CA Framework > > > > which was done by Rohit) we decided to delegate this functionality to > > > > HashiCorp Vault, which will act as > > > > a PKI backend engine for Cloudstack. > > > > > > > > The way I implemented this specific part of the code, is that it can > > > easily > > > > be extended/implemented with other > > > > concrete classes or designs (such as going forward with in-house PKI > > > > engine, or even use external services > > > > such as Let's Encrypt), but at the end of the day we strongly suggest > > to > > > > use Vault, as it is really easy to use. > > > > > > > > > > > > Please find the design document here[1], and share your feedback. I > > will > > > > open up a PR -as is- soon to be able > > > > to have a source code to discuss around it as well. > > > > > > > > [1]: > > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/ > > > > VPN+Implementation+based+on+IKEv2+backed+by+Vault+as+PKI+Engine > > > > > > > > > > > > Thanks > > > > > > > > Khosrow Moossavi > > > > > > > > Cloud Infrastructure Developer > > > > > > > > t 514.447.3456 > > > > > > > > <https://goo.gl/NYZ8KK> > > > > > > > > > > > > > > > > -- > > > Rafael Weingärtner > > > > > > > > > -- > Rafael Weingärtner >
