On Tue, Jul 8, 2014 at 7:00 PM, Dave Thompson 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
>> (http://t
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
>
> 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
> wrote:
> > I figured it out and am now wondering if there is a defect in the openssl
> verify command. This suggestion from Dave Thompson:
>
On Tue, Jul 8, 2014 at 4:48 PM, Barbe, Charles
wrote:
> Also don't these lines of the spec:
>
> countryName ATTRIBUTE ::= {
> WITH SYNTAX PrintableString (SIZE (2))
> -- IS 3166 codes only
> ID
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 th
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 r
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 | 146
On Tue, Jul 8, 2014 at 3:39 PM, Barbe, Charles
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 that helps.
> Pointed m
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 certif
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 signi
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 1
> 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
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 a
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
14 matches
Mail list logo
