-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
-‐‐ Original Message ‐‐‐
On Thursday, 20 May 2021 22:35, tincantech via Openvpn-devel
wrote:
> Hi,
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, 20 May 2021 22:22, Jan Just Keijser janj...@nikhef.nl wrote:
>
> > On 20/05/21
Hi,
On 20/05/21 21:49, tincantech via Openvpn-devel wrote:
Hi,
again, I do not understand why openvpn choose to switch to .pem
for this tutorial. PEM -> Private Email, which this is not.
You have a certificate and a key and every other openvpn tutorial
on openvpn and probably the entire
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
‐‐‐ Original Message ‐‐‐
On Friday, 21 May 2021 00:40, tincantech wrote:
> I would like to hammer one final nail into this discussion.
>
> Openvpn option names and inline tags ALL use ificate .crt and
> .key.
>
> They do not use
Hi,
On Thu, May 20, 2021 at 3:50 PM tincantech via Openvpn-devel
wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi,
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, 20 May 2021 19:30, Arne Schwabe wrote:
>
> > Am 20.05.2021 um 18:56 schrieb tincantech:
> >
> > > Hi,
> > >
On 20/05/21 23:12, tincantech wrote:
[...]
So, why switch to .pem when it has never been used before by openvpn?
If you are all happy to let it go that way then so-be-it,
Hopefully this clarifies things:
- the default output format of OpenSSL is PEM-encoded ; openssl uses the
default
Hopefully this clarifies things:
- the default output format of OpenSSL is PEM-encoded ; openssl uses
the default extension .pem
- the OpenVPN .crt and .key files are ALSO PEM-encoded by default, but
they've just been named differently by the easy-rsa tools to ensure
that the files can be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
‐‐‐ Original Message ‐‐‐
On Thursday, 20 May 2021 22:22, Jan Just Keijser wrote:
> On 20/05/21 23:12, tincantech wrote:
>
> > [...]
> >
> > > > So, why switch to .pem when it has never been used before by openvpn?
> > > > If you are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Thursday, 20 May 2021 22:05, Jan Just Keijser wrote:
> Hi,
>
> On 20/05/21 21:49, tincantech via Openvpn-devel wrote:
>
> > > > Hi,
> > > > again, I do not understand why
From: Lev Stipakov
Add two custom actions to service ovpn-dco driver installation.
- EvaluateDriver
Runs under user privileges. Determines what action (install/uninstall)
should be performed on ovpn-dco component.
- ProcessDriver
Runs under SYSTEM privileges. Performs driver
Hi,
On Thu, May 20, 2021 at 04:56:16PM +, tincantech via Openvpn-devel wrote:
> again, I do not understand why openvpn choose to switch to .pem
> for this tutorial. PEM -> Private Email, which this is not.
https://www.ssl.com/guide/pem-der-crt-and-cer-x-509-encodings-and-conversions/
gert
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
again, I do not understand why openvpn choose to switch to .pem
for this tutorial. PEM -> Private Email, which this is not.
You have a certificate and a key and every other openvpn tutorial
on openvpn and probably the entire planet uses .crt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
‐‐‐ Original Message ‐‐‐
On Thursday, 20 May 2021 19:30, Arne Schwabe wrote:
> Am 20.05.2021 um 18:56 schrieb tincantech:
>
> > Hi,
> > again, I do not understand why openvpn choose to switch to .pem
> > for this tutorial. PEM ->
Am 20.05.2021 um 18:56 schrieb tincantech:
Hi,
again, I do not understand why openvpn choose to switch to .pem
for this tutorial. PEM -> Private Email, which this is not.
You have a certificate and a key and every other openvpn tutorial
on openvpn and probably the entire planet uses .crt and
This is meant to give new users a quickstart for a useable OpenVPN
setup. Our own documentation is lacking in this regard and many
tutorials that can be found online are often questionable in some
aspects.
Linking the individaul RST file on github also give a tutorial
in a nicely formatted way.
Signed-off-by: Arne Schwabe
---
.gitignore | 2 ++
doc/Makefile.am| 25 +
doc/openvpn-examples.5.rst | 17 +
doc/openvpn.8.rst | 2 +-
4 files changed, 41 insertions(+), 5 deletions(-)
create mode 100644
The auth-token check is tied to the username/password that is coming
via a specific SSL session, so keep the state also in the key_state
structure.
This also ensures the auth_token_state is always set to 0 on a new
session since we clear the key_state object at the start of a new
SSL session.
Currently P2P mode of OpenVPN is on of the few places that cannot negotiate
modern OpenVPN features. This becomes more and more problematic since P2P and
P2MP code diverge more and more and also the lack of switching to more
advanced features like Data v2 currently blocks P2P mode from working
When not using username and password (i.e. auth-user-pass) it can still make
to provide the client with an auth-token, e.g. for allowing a session to
continue after a reconnect without requiring 2FA again.
However, without --auth-user-pass openvpn does not have a username and will
ignore any
NCP has proven to be stable and apart from the one VPN Provider doing
hacky things with homebrewed NCP we have not had any reports about
ncp-disable being required. Remove ncp-disable to simplify code paths.
Note: This patch breaks client without --pull. The follow up patch
for P2P NCP will
the socket_info->connection_establish is set through
link_socket_set_outgoing_addr when we reach FULL_SYNC. This patch
introduces a new state in context_auth that replaces the
connection_established state for TLS connections. This make the state
machine easier to understand.
Patch v2: fix p2p
This extract the update of a deferred key status into into own
function.
Patch v2: Do not ignore auth_deferred_expire. Minor format changes.
Signed-off-by: Arne Schwabe
---
src/openvpn/ssl_verify.c | 96 ++--
1 file changed, 62 insertions(+), 34 deletions(-)
The usage of the auth_token_state_flags is tied to the authentication.
The other authentication related flags and status are in the
tls_session struct instead of the tls_multi struct. Move
auth_token_state_flags to the right place.
This also changes that auth_token_initial is set when the token
Previously we relied on checking tls_authentication_status to check
wether to determine if the context auth state is actually valid or not.
This patch eliminates that check by introducing waiting on the
authentication as extra state in the context auth, state machine.
Signed-off-by: Arne Schwabe
Since generating data channel keys does not happen when we have reach the
S_ACTIVE/S_GOT_KEY state anymore like it used to be before NCP, the
state that data channel keys deserves its own state in the TLS session
state machine.
The changes done by this commit are rather intrusive since they
move
24 matches
Mail list logo
