Why does not appear the public key from certificate?

Question

I'm creating a certificate in LAMP, the public key is:

Public Key: 30 81 89 02 81 81 00 CC CB 64 54 C2 FA A3 7A 81 36 5F 1B D5 10 81 75 B7 42 02 31 83 B1 D5 5A 76 72 6A 77 BE 62 69 16 AB EB 39 66 B5 20 39 33 D1 B4 01 7D 23 40 24 9E 60 1C A8 32 83 EA 9D F1 F2 D9 F0 18 85 9D E1 C0 E2 99 FF 89 A4 F9 15 BD 5D BA 3F 39 2E 26 14 48 80 75 EF B5 C0 94 6E 2A 62 D2 42 34 2C 4A 15 17 58 B0 55 98 11 6E 91 FD 28 0D 80 C5 21 C2 3E FB 78 6F 38 31 4A 78 F2 81 2D 85 C9 B8 2B F1 86 C9 02 03 01 00 01

When you enter the site: https://localhost.com
It does not show the public key, but shows the subjects public key.

Modulus (1024 bits):
cc cb 64 54 c2 fa a3 7a 81 36 5f 1b d5 10 81 75 
b7 42 02 31 83 b1 d5 5a 76 72 6a 77 be 62 69 16 
ab eb 39 66 b5 20 39 33 d1 b4 01 7d 23 40 24 9e 
60 1c a8 32 83 ea 9d f1 f2 d9 f0 18 85 9d e1 c0 
e2 99 ff 89 a4 f9 15 bd 5d ba 3f 39 2e 26 14 48 
80 75 ef b5 c0 94 6e 2a 62 d2 42 34 2c 4a 15 17 
58 b0 55 98 11 6e 91 fd 28 0d 80 c5 21 c2 3e fb 
78 6f 38 31 4a 78 f2 81 2d 85 c9 b8 2b f1 86 c9 

Exponent (24 bits):
65537

Why?

Answer 1

(Updated with some background information)

For RSA operations, the public key consists of a modulus the product of two large primes, p and q, which are to be kept as secret, and an exponent, which is typically 65537. Not always, but the binary representation of the latter (only two ones in 17 bits) allows for more efficient operations, so it's very common.

Since the key consists of two numbers, various techniques are available to make sure both are available for processing.

The original question was what this two different format means. If you look carefully, the modulus quoted above is part of the "Public Key" hex string, starting at byte number 8. Also, the ending in binary is 010001, which is 65537 in decimal, therefore it seems that "Public key" is indeed containing both of the values with some binary framing.

With X.509 certificates, most data is encoded with ASN.1 representations. The ASN.1 representation is a very versatile (and complex) representation standard, most commonly encoded in two different formats: DER or PEM. PEM is very easy to recognise as it's using a PGP like BEGIN/END framing, and DER is the raw, binary one. PEM is actually the Base64 encoded DER, with the BEGIN/END lines around it.

To manipulate this data, the three most useful openssl sub-commands are "openssl x509", "openssl asn1parse", and "openssl rsa" (described respectively in the x509(1), asn1parse(1) and rsa(1) manual pages).

As the hex encoding above does not look to represent text, so it seems better to look at it with the asn1parse(1) tool, after converting to binary. I did the conversion by hand, to be used by the xxd(1) tool, usually supplied with the vim(1) package; the "xxd -r" command is used to reverse the hex display of the same command. Again, as this example is quite short, so I simply added the prefix lines, and broke lines at the 16 bytes boundary:

 % cat pub.txt 
 00000000: 3081 8902 8181 00CC CB64 54C2 FAA3 7A81
 00000010: 365F 1BD5 1081 75B7 4202 3183 B1D5 5A76
 00000020: 726A 77BE 6269 16AB EB39 66B5 2039 33D1
 00000030: B401 7D23 4024 9E60 1CA8 3283 EA9D F1F2
 00000040: D9F0 1885 9DE1 C0E2 99FF 89A4 F915 BD5D
 00000050: BA3F 392E 2614 4880 75EF B5C0 946E 2A62
 00000060: D242 342C 4A15 1758 B055 9811 6E91 FD28
 00000070: 0D80 C521 C23E FB78 6F38 314A 78F2 812D
 00000080: 85C9 B82B F186 C902 0301 0001

Now's time to convert to binary, and check if it's really an ASN.1 encoding:

 % xxd -r <pub.txt >pub.bin

 % openssl asn1parse -inform der <pub.bin 
     0:d=0  hl=3 l= 137 cons: SEQUENCE          
     3:d=1  hl=3 l= 129 prim: INTEGER           :CCCB6454C2FAA37A81365F1BD5108175B742023183B1D55A76726A77BE626916ABEB3966B5203933D1B4017D2340249E601CA83283EA9DF1F2D9F018859DE1C0E299FF89A4F915BD5DBA3F392E2614488075EFB5C0946E2A62D242342C4A151758B05598116E91FD280D80C521C23EFB786F38314A78F2812D85C9B82BF186C9
   135:d=1  hl=2 l=   3 prim: INTEGER           :010001

It indeed is - and we can see the two integers described above. Just as an example, we can convert it to PEM, which may look more familiar. We know it's an RSA key, so we can check the rsa(1) tool, and after making sure we specify DER format, and one(!) of the RSA public key variants, it indeed parses the binary successfully:

% openssl rsa -RSAPublicKey_in -inform der <pub.bin   
writing RSA key
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDMy2RUwvqjeoE2XxvVEIF1t0IC
MYOx1Vp2cmp3vmJpFqvrOWa1IDkz0bQBfSNAJJ5gHKgyg+qd8fLZ8BiFneHA4pn/
iaT5Fb1duj85LiYUSIB177XAlG4qYtJCNCxKFRdYsFWYEW6R/SgNgMUhwj77eG84
MUp48oEthcm4K/GGyQIDAQAB
-----END PUBLIC KEY-----

(There is another format actually, which would show up as BEGIN RSA PUBLIC KEY, but the above is usually how the key is represented inside the certificate.)

This all is just an excercise to see what the data supplied in the question actually is. The raw RSA public key is only theoretically useful, as it's handled during the SSL/TLS handshake, and that requires most of the certificate data as well. In theory, you can try following/debugging the handshake, but it's generally more complicated - with PFS, it's not even possible, even if you have the public and private keys. PFS - Perfect Forward Secrecy means there's a random Ephemeral key agreed during the handshake that only the two endpoints know - not even us observing the handshake.

The only useful purpose I've seen that needs actually looking at the public key is to compare the modulus of the public key with the modulus computed from the private key. This is necessary if you want to check which, or if the, private key is corresponding to the public key in the certificate.

The commands to do this are somewhat different, as you usually have the key as part of a certificate (in PEM encoding), and the private key in the RSA format in PEM encoding as well:

% openssl x509 -noout -modulus -in myserver.crt
% openssl rsa -noout -modulus -in myserver.key

The two numbers should match if you want to use them together (sometimes you just compute the md5 for the above outputs, which makes for an easier comparison).