John Wehle wrote:
>
> > More interesting. It looks like a CSR but its broken somewhat. Since
> > there are several forms for the CSR I needed to check the file to be
> > sure.
> >
> > These things can have a PKCS#10 request variant and some other data
> > inside a PKCS#7 wrapper. The wrapper can be either PKCS#7 signed data or
> > PKCS#7 signed data enclosing PKCS#7 enveloped data with the request
> > itself encrypted.
> >
> > Unfortunately in your case the request itself is encrypted using DES and
> > can only be read by the CA it is intended for. You can see this inner
> > structure by using -strparse 51 with asn1parse. It is encrypted using a
> > certificate issued by "Feith Systems and Software, Inc."
>
> That's us. :-) We're exploring the possibility of setting up a private CA
> to support a small number of our PC's in an IPSEC configuration.
>
OK. Well if thats you, does that mean that you have the private key for
the certificate it mentions?
If so it should be possible to decrypt the enveloped-data and get at the
certificate request. There isn't an OpenSSL command line utility to do
this yet. If its just a test private key and certificate then I could do
this if you sent it to me. I'm curious to know what the decrypted bit
inside looks like myself...
> According to [EMAIL PROTECTED] the request uses the CRS protocol
> which is documented in draft-ietf-smime-crs-00.txt which was attached
> to his email. Unfortunately I'm not currently up on the terminology,
> however my impression is that the certificate returned by the CA doesn't
> have to be inside a PKCS#7 wrapper (though it's recommended). So it
> sounds like if I can dig the PKCS#10 request out of the PKCS#7 wrapper
> then I should be able to use openssl to issue the certificate in the
> normal fashion and the router should accept the new certificate.
>
You can but the inner stuff is encrypted so you need to decrypt it
first... its encrypted using PKCS#7 enveloped-data and as I said OpenSSL
doesn't have a utility to handle that at present.
>
> Okay that gives:
>
> subject=/unstructuredName=prepnet-rt.FEITH.COM
> issuer= /unstructuredName=prepnet-rt.FEITH.COM
> -----BEGIN CERTIFICATE-----
> MIIBUjCB/QIgNUY4ODI0NUVFRDhBQTU1NDg2OTJCNEVBQjk4MDc5MjkwDQYJKoZI
> hvcNAQEEBQAwJTEjMCEGCSqGSIb3DQEJAhYUcHJlcG5ldC1ydC5GRUlUSC5DT00w
> HhcNOTMwMzA2MDEyNDI2WhcNMDMwMzA0MDEyNDI2WjAlMSMwIQYJKoZIhvcNAQkC
> FhRwcmVwbmV0LXJ0LkZFSVRILkNPTTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQD3
> AwyLSUkP/mb8YesXG8maybRS8XlKZECW+54wIC6YriutTz3bAhxAsCCwC1j8NR//
> LD2ajFOTLoDBd/LvRtGnAgMBAAEwDQYJKoZIhvcNAQEEBQADQQDYrU9mbbrxjGmO
> H5vdUMGkQOFn2f5futSkML3EElzKWTEdYcp6maOzqVF7K/e4ysc/6WdKorhb3BCj
> hah3zd9T
> -----END CERTIFICATE-----
>
> Converting it from base64 and dumping the asn1 stream gives:
>
[asn1 dump deleted]
>
> Now what?
Now it gets tricky. The only bit that is any real use is the public key.
I assume you can't extract the private key corresponding to this
request? If you can then either create your own request (and ignore the
one it included) or turn the certificate into a request.
Failing that it should be possible to manually dump the public key into
a certificate but some extra code would be needed to do that, basically
turning off various signature checks in the code because we don't have
the proper private key and need to stuff something bogus in there.
Before something yucky like that is attempted I'd suggest trying to
decrypt the other stuff first.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
