[strongSwan] Can't load certificates and keys via symlink

[Noel Kuntze]

On 11.02.2017 12:03, Jose Novacho wrote:
>> You are still trusting a public CA to not issue another certificate for that server to a malicious third party.
> 
> I'm not sure I'm following. How can public CA generate certificate for my server to someone, who doesn't have access to my server? That would totally break the SSL/HTTPS as it is used now. If anyone could generated certificate to any domain, what would be the point of using certificate to validate identity of servers?  I have don't really know that much about this stuff, but this was one thing I thought I knew.

Bugs in the validation system or they just do it. It happens every year and public CAs do funny stuff all the time. Yes, that is why TLS with public CAs is (still) broken.
The point is to make it easy and seemingly secure for users to access your resources. 


> 
> Also only other issue than to use public CA I know is to use self-signed CA. And if I use self-signed, no one is obligated to trust it. As anyone can create self-signed certificates.

No one is obliged to trust any CA. To trust a CA, the root certificate of it has to be locally available and trusted.

> 
> My goal is to have the VPN available for occasional friend, so we can play some games on LAN. By using the LE certificate, he does not have to do anything apart from fill in the username/password. The LE certificates are trusted by Windows, so there is no fiddling with that.
> 

I guess that's then okay, but make sure they can only access the services and systems that are actually needed.


> On 10. 2. 2017 14:59, Noel Kuntze wrote:
>> On 10.02.2017 12:17, Jose Novacho wrote:
>>> It seems we are talking about two different things.
>> I know that and it is deliberate. The things I describe are issues that will, albeit at some arbitrary point in the future,
>> be encountered by you, if you do not fix them now.
>>
>>> I have used the LetsEncrypt certificate to authenticate the server itself. Peers are using username and password using EAP, that's not an issue.
>> You are still trusting a public CA to not issue another certificate for that server to a malicious third party.
>>
>>

-- 

Mit freundlichen Grüßen/Kind Regards,
Noel Kuntze

GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 866 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170211/4c92f84b/attachment.sig>