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 :-)
Best Answer
I get significantly different output when I use
than when I use
The public key file created by
openssl rsa -puboutdoes successfully verify the message. It appears that ssh-keygen's-m pemfile format for public keys isn't compatible with whatopensslis expecting. In fact, reading the public key info with theopenssl rsa -textcommand requires-RSAPublicKey_inwhich doesn't seem to be a supported option fordgst.