On 03/05/2016 06:27 PM, Gert Doering wrote:
> Hi,
>
> On Sat, Mar 05, 2016 at 12:58:06AM +0300, ValdikSS wrote:
> If Connect works, and OpenVPN for Android does not, this hints at
> "PolarSSL vs. OpenSSL".
>
> Or at "we call the crypto library differently"...
Yes, PolarSSL build of OpenVPN 2.3 wor
Hi,
On Sat, Mar 05, 2016 at 12:58:06AM +0300, ValdikSS wrote:
> Bad news:
>
> * OpenVPN 2.3 and master can't connect to this server, with both OpenSSL
> and PolarSSL backends. Maybe if I supply certificates in correct order,
> client would
If Connect works, and OpenVPN for Android does not,
On 03/05/2016 12:58 AM, ValdikSS wrote:
> I have good news and bad news:
>
> Good news:
>
> * OpenVPN sends all certificates from the server supplied for --server
> directive (although with a small bug that a certificate which you have
> private key
> for must be supplied on the top)
> *
On 03/05/2016 08:24 AM, ValdikSS wrote:
>
>
> On 03/05/2016 04:36 AM, Jan Just Keijser wrote:
>
> I've signed my new CA's private key (4096 bit) with old CA (1024 bit) and it
> became intermediate to my old CA (what you call extending trust), but also
> issued
> self-signed new CA. I issue server
On 03/05/2016 04:36 AM, Jan Just Keijser wrote:
> Hi,
>
> On 04/03/16 22:58, ValdikSS wrote:
> how did you generate the cross-signed CA certs? I've looked around but all
> cross-signing either requires you to use the same private key (i.e. bit size)
> or
> that you extend the trust of one CA wi
Hi,
On 04/03/16 22:58, ValdikSS wrote:
I have good news and bad news:
Good news:
* OpenVPN sends all certificates from the server supplied for
--server directive (although with a small bug that a certificate
which you have private key for must be supplied on the top)
* OpenVPN Conn
I have good news and bad news:
Good news:
* OpenVPN sends all certificates from the server supplied for --server
directive (although with a small bug that a certificate which you have private
key for
must be supplied on the top)
* OpenVPN Connect for Android can successfully connect to
On 03/04/2016 11:08 PM, Jan Just Keijser wrote:
> Hi,
>
> On 04/03/16 14:24, Arne Schwabe wrote:
> the more I think about it, the more I think that what you are trying to
> achieve ought not to work:
>
> your current situation is this:
> - clients are equipped with a 1024bit CA cert; the server ce
Hi,
On 04/03/16 14:24, Arne Schwabe wrote:
Am 04.03.16 um 14:18 schrieb ValdikSS:
On 03/04/2016 04:12 PM, Arne Schwabe wrote:
Am 03.03.16 um 22:04 schrieb ValdikSS:
Shouldn't sending the new CA chain only be enough? Since it is
(cross)signed by the old CA, the client will accept it. For the o
On 03/04/2016 03:26 PM, Jan Just Keijser wrote:
> Hi,
>
> On 03/03/16 22:04, ValdikSS wrote:
> it's possible to send a stacked CA certificate (i.e. server certificate
> and intermediate CA cert) from server to the client. We use this in
> production, and it is done by simply stacking (cat'ing) th
Am 04.03.16 um 14:18 schrieb ValdikSS:
> On 03/04/2016 04:12 PM, Arne Schwabe wrote:
>> Am 03.03.16 um 22:04 schrieb ValdikSS:
>> Shouldn't sending the new CA chain only be enough? Since it is
>> (cross)signed by the old CA, the client will accept it. For the old
>> clients the new CA will look l
On 03/04/2016 04:12 PM, Arne Schwabe wrote:
>
> Am 03.03.16 um 22:04 schrieb ValdikSS:
> Shouldn't sending the new CA chain only be enough? Since it is
> (cross)signed by the old CA, the client will accept it. For the old
> clients the new CA will look like an intermediate certificate.
Please clar
On 03/04/2016 03:57 PM, David Woodhouse wrote:
> On Fri, 2016-03-04 at 15:37 +0300, ValdikSS wrote:
> What you described *was* chained certificates, wasn't it?
>
> From the point of view of a client which only trusts the old CA, the
> server is presenting a chain — its own cert, followed by the
> "
Am 03.03.16 um 22:04 schrieb ValdikSS:
> Hello everyone,
>
> I'm trying to leisurely move from an old existing 1024 bit CA to a new 4096
> bit one without a hassle for a clients.
> From a X.509 perspective it shouldn't be a problem, and I already have new CA
> self-signed and cross-signed with
On Fri, 2016-03-04 at 15:37 +0300, ValdikSS wrote:
> Thanks for the information. It definitely doesn't work for any
> certificate, probably only for chained certificates.
What you described *was* chained certificates, wasn't it?
From the point of view of a client which only trusts the old CA, the
Thanks for the information. It definitely doesn't work for any certificate,
probably only for chained certificates.
That's a good news that there's no protocol limitation for this. I'll check the
code to see what's going on.
On 03/04/2016 03:26 PM, Jan Just Keijser wrote:
> Hi,
>
> On 03/03/16 2
Hi,
On 03/03/16 22:04, ValdikSS wrote:
Hello everyone,
I'm trying to leisurely move from an old existing 1024 bit CA to a new 4096 bit
one without a hassle for a clients.
From a X.509 perspective it shouldn't be a problem, and I already have new CA
self-signed and cross-signed with old CA, i
Currently I did the same, but it would be much easier to just push 2
certificates from server.
On 03/04/2016 06:40 AM, Илья Шипицин wrote:
> we are running openvpn for ~ 1000 users, in similar case we deployed new ca
> on separate udp port and re-deployed installer to our users (we put installer
Hello everyone,
I'm trying to leisurely move from an old existing 1024 bit CA to a new 4096 bit
one without a hassle for a clients.
From a X.509 perspective it shouldn't be a problem, and I already have new CA
self-signed and cross-signed with old CA, it should work just fine.
While there's no
19 matches
Mail list logo