On 02-06-05 15:43:45 CEST, Rich Salz wrote:
Richard Levitte via RT wrote:
Can I assume that sed exists and works properly? dirname can be
coded like this:
echo $$i | sed -e 's|[^/]*$||' -e 's|/$||'
dirname foo returns . which the above doesn't catch.
I can only think of the
`x509 -noout -text` prints inconsistent output.
... openssl x509 -noout -text -in old.pem | grep Issuer:
Issuer: [EMAIL PROTECTED], CN=CA UCO, O=Universidad de Cordoba, C=ES
... openssl x509 -noout -text -in new.pem | grep Issuer:
Issuer: C=ES, O=Universidad de Cordoba, CN=AC
the DN handling in openssl seems to be a little uneven.
getting special characters in seems to be no problem when using the
interactive interface (at least when 'special' restricts itself to the
ASCII characters with special syntactic function).
but as soon as it comes to looking at the result,
On 02-04-16 16:49:25 CEST, Richard Levitte - VMS Whacker wrote:
BTW, thinking about it, I'm not sure why this discussion acme up at
all. Certificates are often stored as attributes of a record (eh,
terminology isn't a strength of mine, so if record isn't the proper
term, please pardon me),
On 02-04-16 11:02:58 CEST, Howard Chu wrote:
the order of everything. Certificates are specified in X.509 and are
properly
a part of the X.500 family, and the X.500 DN syntax is clearly specified.
the syntax is clearly specified, but the only thing that i could find
about the RDN order is
On 02-04-16 10:51:31 CEST, Howard Chu wrote:
At its core, LDAP is simply a different front-end for the X.500 information
model. A DN is a name that uniquely identifies an object in the X.500 name
space. Practically speaking, a DN is a DN. In pure X.500, DNs are specified
to be big-endian,
i sent this to -users a few days ago, but perhaps the people who know
the answer only hang around on -dev...?
rj
---BeginMessage---
when i create a client certificate using a mozilla browser, a CGI script
generates an SPKAC file for use with `openssl ca -spkac infile`.
the DN then becomes of
On 02-03-26 12:09:59 CET, Robert Joop wrote:
On 02-03-25 18:03:56 CET, Stephen Sprunk wrote:
Here's the more interesting question: why do we have a switch for
UTF-8 encoding, instead of determining it from the user's locale?
what is the canonical way to detect this?
following up
On 02-03-26 15:01:37 CET, George Rogers wrote:
Have you guys forgotten that the client and server are on different ends of
the
wire? Which end of the wire is going to use the certificate? Which end of
the
wire is creating the certificate? The switch has to be there to allow
creation
the explanation of the -utf8 option doesn't make sense, does it?
quote src=http://www.openssl.org/docs/apps/req.html;
-utf8
this option causes field values to be interpreted as UTF8 strings, by default they
are interpreted as ASCII. This means that the field values, whether prompted from a
On 02-03-19 23:05:52 CET, Dr S N Henson wrote:
I can't see how that can happen. The ca command only passes the issuing
CA certificate to the extension routines. It does not have access to any
other CA certificate. It fills in the authority key identifier by
extracting the issuer name of that
On 00-07-11 23:25:44 MET DST, Richard Levitte - VMS Whacker wrote:
From: Robert Joop [EMAIL PROTECTED]
Please try the latest snapshot and see if that helps. No guarantees,
though...
rj OpenSSL version: 0.9.5a
rj Last change: Make sure _lrotl and _lrotr are only used with MSVC
12 matches
Mail list logo
