On Tue, Nov 30, 2004, Dr. Stephen Henson wrote:
> On Mon, Nov 29, 2004, Manfred Faulandt wrote:
>
> >
> > Many thanks for the very competent answer. We noticed the UTF8 encoding
> > but thought about it as a "why not?" matter (and we didn't look into a
> > RFC neither).
> >
> > The CA is a Mi
On Mon, Nov 29, 2004, Manfred Faulandt wrote:
>
> Many thanks for the very competent answer. We noticed the UTF8 encoding
> but thought about it as a "why not?" matter (and we didn't look into a
> RFC neither).
>
> The CA is a Microsoft Shop and Internet Explorer is happy with the
> certifica
On Mon, Nov 29, 2004, Manfred Faulandt wrote:
> Steve,
>
> Many thanks for the very competent answer. We noticed the UTF8 encoding
> but thought about it as a "why not?" matter (and we didn't look into a
> RFC neither).
>
> The CA is a Microsoft Shop and Internet Explorer is happy with the
>
Steve,
Many thanks for the very competent answer. We noticed the UTF8 encoding
but thought about it as a "why not?" matter (and we didn't look into a
RFC neither).
The CA is a Microsoft Shop and Internet Explorer is happy with the
certificates they issue. I'll check their site again for somthin
On Mon, Nov 29, 2004, Manfred Faulandt wrote:
> Dear group,
>
> I have a server certificate signed by a local CA company and the root
> certificate that signed it expires very soon. The CA company gave us a
> new root certificate but with the new root certificate OpenSSL is no
> longer able t
Chris,
this is the issue... the public key and private key of trust.pem are
not the same as the keys for trust_new.pem. They have the same fields
in the DN, but do not share the same keys (if they do then this is bad
practice by the issuers), so it is a different key that signed the
a-sign.pem and
Manfred,
> since the public key of trust_new.pem is the same as that of trust.pem
> it should make no difference when it comes to decrypting the hash of
> a-sign.pem ... but I might be totally wrong of course as well...?
this is the issue... the public key and private key of trust.pem are
not the
Hello Chris,
You can not just replace the trust.pem with trust_new.pem as the new
root ca cert (trust_new.pem) did not sign the sub ca cert (a-sign.pem)
and so the chain is broken. They need to give you a new ca cert and
server cert.
Thanks for the answer. I must admit that I'm not very familiar
Hello there,
> I have a server certificate signed by a local CA company and the root
> certificate that signed it expires very soon. The CA company gave us a
> new root certificate but with the new root certificate OpenSSL is no
> longer able to successfully verify the server certificate.
>
> Th
Dear group,
I have a server certificate signed by a local CA company and the root
certificate that signed it expires very soon. The CA company gave us a
new root certificate but with the new root certificate OpenSSL is no
longer able to successfully verify the server certificate.
The working c
10 matches
Mail list logo
