I've commented on the PR, mostly about not understanding the commit
message RFC-references and indentation error.
Overall the PR looks good to me, but I'd like someone who is more
familiar with implementation have a look at it.
Best Regards
Eine Kleine Blau Fisch
On Tue, Feb 19, 2019 at 2:10 PM
root:root, chmod 400. And ideally your Root CA files should not be
hosted on your web server, otherwise a server compromise also
compromises your root authority.
https://redmine.lighttpd.net/projects/1/wiki/docs_ssl
Permissions
Be careful to keep your .pem file private! Lighttpd reads all
You can find a number of SM2 implementations on github, etc.
https://github.com/openssl/openssl/blob/9453b196343db579c590130adc63d35d2ff87188/crypto/sm2/sm2_crypt.c
https://github.com/ARMmbed/mbedtls/blob/3ea8c4cb2a03724ba15c915e02d83255e1884859/library/ecdsa.c
at 10:13 AM Richard Levitte wrote:
>
> In message
> on Tue,
> 16 Oct 2018 10:34:31 +0200, Peter Magnusson
> said:
>
> > Sorry, I am an idiot =)
>
> No you're not.
>
> > Problem resolved, user error. -key was the problem and should not be
> > u
igure out what pass phrased was
> passed and where it came from. I'm afraid that's a debugging session.
>
> Cheers,
> Richard
>
> In message
> on Tue,
> 16 Oct 2018 09:54:08 +0200, Peter Magnusson
> said:
>
> > The error can be workaround by entering PIN = &
The error can be workaround by entering PIN = "..." into [pkcs11_section].
pkcs11 engine version is libp11-0.4.9.
Anyone know if this a 1) libp11 issue or 2) openssl issue or 3) me
doing something wrong?
On Mon, Oct 15, 2018 at 5:40 PM Peter Magnusson
wrote:
>
> Hi,
>
> I'
Hi,
I'm trying to understand how to make "openssl ca" prompt for a PKCS#11
login pin. Version is openssl-1.1.1.
openssl req works as I would expect, prompting for PIN:
YUBIHSM_PKCS11_CONF=yubihsm2-pkcs11.conf \
local-build/bin/openssl \
req -config yubihsm2-openssl.conf -new \
-engine pkcs11
You would be better off with AES-CCM or such for your backup, that
gives you the integrity check.
i.e. you would be reasonably sure what you decrypt is encrypted with your key.
So the fist question would be why even consider AES-CBC? Somewhere in
the decision process you ought to go "Is the
6bcd7581f9ba9cb2baf3
> Does that address your concerns?
I think so! I'll integrate it into my tests and try to do Q/A on the
change, see if I can figure out any other edge case.
Best Regards
//P
On Mon, Oct 8, 2018 at 6:15 PM Viktor Dukhovni
wrote:
>
> > On Oct 8, 2018, at 8:47 AM, P
=true, max_pathlen=0
key usage : Key Cert Sign, CRL Sign
! The certificate is not correctly signed by the trusted CA
The handshake fails after this error, mbedtls_ssl_handshake returned -9984.
On Mon, Oct 8, 2018 at 2:51 PM Peter Magnusson
wrote:
>
> sorry, typo on the verif
sorry, typo on the verify line, this was what I should have written:
VERIFY(max_path_length>0) error upon preparing transition from i=2
(EvilCA) to i=2 (EvilServer).
On Mon, Oct 8, 2018 at 2:47 PM Peter Magnusson
wrote:
>
> That is not correct behaviour as far as I can understand.
&g
interpretation that 0 pathlen on the root self signed meant
> infinite.
> The pathlen only applies on the certs between root and the leaf (which
> obviously can be 0, and CA true or not, but bad form to say true I'd imagine.)
>
> On Mon, Oct 8, 2018 at 1:57 AM Peter Magnusson
One more logic confusion in the OpenSSL Path Length Constraint check.
Any Path Length Constraint set by Root (or any other Self-Issued
Certificate) is ignored.
Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly
applied to the checker (i.e. the checker and the calculation logic
have
Thanks, I provided some input regarding off by one calculation of plen
still present in the patch.
You are very much correct on the definition of self-issued; rfc5280,
"A certificate is self-issued if the same DN appears in the subject
and issuer fields (the two DNs are the same if they match
d:17:49:AA:01:F6:25:85:23:3F:A6:7A:43:D3:97:2A:F8:74:27:89:A0
On Thu, Oct 4, 2018 at 12:26 PM Viktor Dukhovni
wrote:
>
> On Wed, Oct 03, 2018 at 07:16:51PM +0200, Peter Magnusson wrote:
>
> > The following test case attempts to validates evilserver.pem, issued
> > by evilca.
Is this expected? (plen > (x->ex_pathlen + proxy_path_length + 1))
evaluates to false (constraint not violated) when checking constraint
0 against plen=1 (constraint violated as far as I can understand?).
Doesn't make much sense to me. Is there something I haven't understood
about how the
asic"
X509v3 Basic Constraints: critical
CA:TRUE
openssl verify -verbose -CAfile root.pem -untrusted untrusted.pem evilserver.pem
evilserver.pem: OK
On Wed, Oct 3, 2018 at 4:51 PM Viktor Dukhovni
wrote:
>
> On Wed, Oct 03, 2018 at 02:51:57PM +0200, Peter Mag
Hi,
It is my understanding "openssl verify" should raise
X509_V_ERR_PATH_LENGTH_EXCEEDED should be raised if pathlen=0
intermediate issues a new CA, but that does not seem to occur when I
test with a couple pf openssl versions.
I am not sure due to limited understanding of the code, but I am
18 matches
Mail list logo
