Thanks for the reply Tom and Kyle H.
Now i have below 2 questions:
(1) Based on application's need, can we assume return codes 2, 3 and 4 as
non-CA ?
(2) If we get return code 4 basicConstraints absent but keyUsage present
and keyCertSign asserted for a certificate, is this a valid certificate ?
This is unfortunately something that you need to figure out for yourself.
The controlling standard is not RFC 3280, or in fact any of the RFCs.
It is X.509, available from http://www.itu.int/. (You can get the
latest ratified edition for no cost.)
However:
2 should probably not be considered
The controlling standard is not RFC 3280, or in fact any of the RFCs. It is
X.509, available from http://www.itu.int/. (You can get the latest ratified
edition for no cost.)
If its a server certificate issued by a CA intended to be consumed by
browsers (or other related services), then the CA
I am new to this forum so please excuse me if I do not do this right.
I am working on a z/OS 1.13 system aka OS/390 aka MVS.
We have the need to parse X509 certificates. We were using an older version,
0.9.6a, but found that it did not interpret new signing algorithms correctly. I
pulled down
Am 08.07.2014 18:10, schrieb T. Travers:
I am new to this forum so please excuse me if I do not do this right.
I am working on a z/OS 1.13 system aka OS/390 aka MVS.
We have the need to parse X509 certificates. We were using an older
version, 0.9.6a, but found that it did not interpret new
I figured it out and am now wondering if there is a defect in the openssl
verify command. This suggestion from Dave Thompson:
I would first try x509 -noout -subject|issuer -nameopt multiline,show_type
and see if that helps.
Pointed me in the right direction. What i found was that Issuer for
On Tue, Jul 8, 2014 at 3:39 PM, Barbe, Charles
charles.ba...@allworx.com wrote:
I figured it out and am now wondering if there is a defect in the openssl
verify command. This suggestion from Dave Thompson:
I would first try x509 -noout -subject|issuer -nameopt multiline,show_type
and see if
Yet openssl verify said OK to both of my certificates against the CA
certificate... so is it incorrectly neglecting to compare the types when it
tries to build the chain of certificates?
Charles A. Barbe
Senior Software Engineer
Allworx, a Windstream company
245 East Main St | Rochester NY |
Also don't these lines of the spec:
countryName ATTRIBUTE ::= {
WITH SYNTAX PrintableString (SIZE (2))
-- IS 3166 codes only
ID id-at-countryName }
indicate that countryName is
You need to compile the FIPS module and then a version of OpenSSL that
uses that module. See https://www.openssl.org/docs/fips/UserGuide.pdf
for links to appropriate documentation, depending on which version of
the FIPS module you need to use (probably the latest one if you don't
know you need
On Tue, Jul 8, 2014 at 4:48 PM, Barbe, Charles
charles.ba...@allworx.com wrote:
Also don't these lines of the spec:
countryName ATTRIBUTE ::= {
WITH SYNTAX PrintableString (SIZE (2))
-- IS 3166 codes only
From: owner-openssl-us...@openssl.org On Behalf Of Jeffrey Walton
Sent: Tuesday, July 08, 2014 16:20
On Tue, Jul 8, 2014 at 3:39 PM, Barbe, Charles
charles.ba...@allworx.com wrote:
I figured it out and am now wondering if there is a defect in the openssl
verify command. This suggestion
On Mon, Jul 07, 2014, Dave Thompson wrote:
The only thing that springs to mind that could be invisible is string types
and
some options of the cert Issuer fields vs the CA Subject. RFC 5280 requires
a
fairly complicated Unicode-aware comparison algorithm which I believe
openssl
does
On Tue, Jul 8, 2014 at 7:00 PM, Dave Thompson dthomp...@prinpay.com wrote:
From: owner-openssl-us...@openssl.org On Behalf Of Jeffrey Walton
Sent: Tuesday, July 08, 2014 16:20
...
Not sure if this is any consolation, but countryName is a
DirectoryString, and PrintableString is OK per RFC 5280
14 matches
Mail list logo
