Hi Erwann,
On 07/03/19 11:35, Erwann Abalea via openssl-users wrote:
Bonjour,
Here, reject the certificate is the correct behaviour, IMO.
UTCTime/GeneralizedTime are defined in X.680.
UTCTime:
- can have no timezone information, or have Z, of have a timezone offset
(with hours and
Bonjour,
Here, reject the certificate is the correct behaviour, IMO.
UTCTime/GeneralizedTime are defined in X.680.
UTCTime:
- can have no timezone information, or have Z, of have a timezone offset (with
hours and minutes)
- can be precise up to the second, or be precise up to the minute
-
Hi all,
On 06/03/19 16:36, Jakob Bohm via openssl-users wrote:
On 06/03/2019 16:17, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
Behalf Of
Richard Levitte
Sent: Wednesday, March 06, 2019 03:07
On Wed, 06 Mar 2019 10:52:44 +0100,
Jan Just Keijser
On 06/03/2019 16:17, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
Richard Levitte
Sent: Wednesday, March 06, 2019 03:07
On Wed, 06 Mar 2019 10:52:44 +0100,
Jan Just Keijser wrote:
as a follow-up: Richard's analysis/suspicion was spot on.
Since OpenSSL is more than just a TLS implementation, I agree with Michael and
support relaxing these checks when appropriate.
Regards,
Uri
Sent from my iPhone
On Mar 6, 2019, at 10:22, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
>>
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Richard Levitte
> Sent: Wednesday, March 06, 2019 03:07
>
> On Wed, 06 Mar 2019 10:52:44 +0100,
> Jan Just Keijser wrote:
> > as a follow-up: Richard's analysis/suspicion was spot on.
> > However, it was the *server*
On Wed, 06 Mar 2019 10:52:44 +0100,
Jan Just Keijser wrote:
> as a follow-up: Richard's analysis/suspicion was spot on.
> However, it was the *server* side certificate that was causing the
> error, and the server certificate does indeed contain a poorly
> formatted date:
>
> $ openssl asn1parse
Hi all,
On 04/03/19 10:01, Richard Levitte wrote:
The format error refers to how the numbers are encoded in the
certificate. The best way to see for ourselves is if you can run
'openssl asn1parse' on the certificate and show us the sequence that
contains the notBefore and notAfter time-stamps.
Hi Richard,
On 04/03/19 10:27, Richard Levitte wrote:
On Mon, 04 Mar 2019 10:06:54 +0100,
Jan Just Keijser wrote:
...
Having said that, I just created a certificate set to expire on Mar 9 2037 and
it passed the
following command:
c:\program files\openvpn\bin\openssl x509 -dates -subject
On Mon, 04 Mar 2019 10:06:54 +0100,
Jan Just Keijser wrote:
...
> Having said that, I just created a certificate set to expire on Mar 9 2037
> and it passed the
> following command:
> c:\program files\openvpn\bin\openssl x509 -dates -subject -noout -in
> mycert.crt
>
> can you run the same
Hi,
On 04/03/19 09:08, Wolfgang Knauf wrote:
Hi,
I first asked this question in the OpenVPNGui forum, and they redirected me to here: OpenVPNGui 2.4.6 works with a customers
server certificate, but it fails when using 2.4.7.
Here is the thread in the OpenVPNGui forum:
The format error refers to how the numbers are encoded in the
certificate. The best way to see for ourselves is if you can run
'openssl asn1parse' on the certificate and show us the sequence that
contains the notBefore and notAfter time-stamps. The are seen
together between the issuer name and
12 matches
Mail list logo
