Convert from P7B to PEM via OpenSSL

The structure of this IIS7 renewal request is actually quite elegant. It seems to start from the premise that because this is a request to renew a current certificate, it needs to prove that the request is coming from the correct host -- i.e. the host that is actually using the current certificate & ∴ owns the associated private key. In the Internet world, you prove that you are allowed to request renewals for a certificate by authenticating to your CA as the original user, rather than creating a signed CSR.

To prove the right to issue a renewal request, IIS7 creates a normal CSR (PKCS#10 object), and then signs it, and provides the cert of the key that signed it.

• IIS7 renewal CSR
  • PKCS#7 Data
    • PKCS#10 Data (the ordinary CSR)
  • Normal server certificate
  • Issuing CA data
  • RSA signature (I assume)

Use openssl asn1parse -in iis7rcsr -i to see the structure of the file, and compare this to normal CSRs. You should see an OCTET STRING near the beginning, in an object labelled ":pkcs7-data", which is what you need to extract to get the CSR.

$ openssl asn1parse -in iis7rcsr -i
0:d=0  hl=4 l=4273 cons: SEQUENCE          
4:d=1  hl=2 l=   9 prim:  OBJECT            :pkcs7-signedData
15:d=1  hl=4 l=4258 cons:  cont [ 0 ]        
19:d=2  hl=4 l=4254 cons:   SEQUENCE          
23:d=3  hl=2 l=   1 prim:    INTEGER           :01
26:d=3  hl=2 l=  11 cons:    SET               
28:d=4  hl=2 l=   9 cons:     SEQUENCE          
30:d=5  hl=2 l=   5 prim:      OBJECT            :sha1
37:d=5  hl=2 l=   0 prim:      NULL              
39:d=3  hl=4 l=2426 cons:    SEQUENCE          
43:d=4  hl=2 l=   9 prim:     OBJECT            :pkcs7-data
54:d=4  hl=4 l=2411 cons:     cont [ 0 ]        
58:d=5  hl=4 l=2407 prim:      OCTET STRING      [HEX DUMP]:3082096330820...

In order to get the actual PKCS#10 CSR out of here, we need that offset number, "58" in this example. Then we can use that offset to extract the binary version of that object :-

$ openssl asn1parse -in iis7rcsr -strparse 58 -out thecsr -noout

Next we can read that output file 'thecsr' with openssl req, remembering to specify the input format DER.

$ openssl req -in thecsr -inform DER -text -noout
Certificate Request:
Data:
    Version: 0 (0x0)
    Subject: (normal CSR Subject: line, censored)
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
...

I can wrap all this up into one command-line with no temporary files (but sadly 2 reads of the original cert), as long as I can use Linux's /proc/self/fd/ to fool openssl (it will do native tricks with file descriptors for password handling, but not normal output).

$ openssl asn1parse -in iis7rcsr -strparse $(openssl asn1parse -in iis7rcsr | grep -A2 ':pkcs7-data'|tail -1|cut -d: -f1) -out /dev/stdout -noout | openssl req -inform DER -noout -text

Certificate Request:
Data:
    Version: 0 (0x0)
    Subject: (Subject: line censored again)
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
        RSA Public Key: (1024 bit)
            Modulus (1024 bit):
...

This long command line is directly equivalent to the simple openssl req -in non-iis7rcsr -noout -text that I normally use :-)

SSL X509 certificate file is a file containing a certificate in the format specified by the ITU in their X series of specifications - specifically x.509. There is no private-key information there as it is a certificate format so things like names, public keys, signatures, validity dates and other goodies go in there - but not private-keys.

PEM is a set of specifications for Privacy Enhanced Mail - it offers for the most part packaging standards that are build off of the PKCS specs (PKCS specs were developed by RSA and RSA labs themselves for public use to enable interoperability between various implementations - this was done again by the IETF and by the community in other arenas). You can use openssl to convert formats around - see here http://www.openssl.org/docs/apps/openssl.html . Concatenation won't help you any.

If the certificate is self-signed then it's kind of odd that a CA gave it to you - that makes me think that you are telling about feeding the Gandi CA certificate to openssl which is telling you that cert is self signed (ergo it is a root or end entity certificate but certainly not an intermediate aka chain certificate).

To address some of your points: 1 Self signed certs will always generate warnings in good clients because they lack trust until the user decides they are trustworthy (or for most users.. until Microsoft , Mozilla Foundation, Google, or Opera) decides the user should trust that CA). If your clients (browsers or whatever) have the CA stored and marked as trusted then this warning won't pop-up. 2 Possibly 3 Looks like you used the right key and CSR with Gandi 4 Looks to me like you need to load the domain key and cert and possibly CA into OpenSSL either via OS level trust configuration or via Stud configuration.