Re: [strongSwan] A couple of offerings for the community

2019-01-29 Thread Derek Cameron
On Mon, Jan 28, 2019 at 2:29 AM Tobias Brunner  wrote:
> Does Windows require the complete chain for the client
> certificate?

If you deliberately delete the CA certificate of the client
certificate on Windows, then when you try to connect, you will get an
error message in red, "Invalid certificate type." This is an
"all-purpose" error message Windows gives when it does not like
something about your certificates. If you look in Windows Event
Viewer, you will see an error from source RasClient saying, "The error
code returned on failure is 13819." Again, this is an "all-purpose"
error code for certificates.

Derek.


Re: [strongSwan] A couple of offerings for the community

2019-01-28 Thread Tobias Brunner
Hi Derek,

> Originally I wanted to use p12 files with everything in them (CA cert,
> client cert, client key), but this created messiness on the Windows
> end.

As mentioned in the previous mail, the CA certificate that issued the
client and server certificates don't have to be the same (often they
aren't).  Does Windows require the complete chain for the client
certificate?

> This is why I separated out the CA cert, with the client cert and
> the client key going into a pfx file.

Because you expect the PKCS#12/PFX file in local.p12 to contain CA
certificates?  That isn't necessarily the case, it could just as well be
only the client certificate and key (because the issuing CA certificate
is not required on Android).  Providing CA certificates to verify the
server certificate (if it's even necessary) via remote.cert is usually
better anyway as that avoids warnings on older Android releases (and
maybe cleaner if the CAs are different).

Regards,
Tobias


Re: [strongSwan] A couple of offerings for the community

2019-01-28 Thread Tobias Brunner
Hi Derek,

> (1) An IKEv2 profile importer for Windows 10, modeled on the
> strongSwan profile importer for Android:
> https://github.com/dcamero2016/vpn-importer

Nice idea.  local.ca is wrong, though, it's the CA certificate to verify
the remote's certificate, it hasn't necessarily anything to do with the
client's authentication or certificate (i.e. should be remote.ca, or
remote.cert to keep it compatible with our format).  And why change
local.p12 to local.pfx?  (It's still a PKCS#12 container, no?)

Regards,
Tobias