MSCEP cert requests generate keys that are too small

Unanswered Question
Jul 9th, 2010

I am doing certificate authentication for site to site VPNs. I am using MSCEP to obtain the certs from my MS Windows CA. The (remote) router requesting the certs is an 891 running IOS 12.4(22)YB.

The following config/commands are used to get the cert:

crypto pki trustpoint MY-CA
enrollment mode ra
enrollment url
usage ike
revocation-check none
crypto pki certificate storage flash:/CERTS/
crypto ca authenticate MY-CA
crypto ca enroll MY-CA

This all works fine but the key that gets generated during the MSCEP request is only 512 bytes which is too small for SSH version 2. Getting a new cert causes the SSH service on the 891 to revert to version 1.5.

Is there some way to specify that the keys that the MSCEP requests auto-generate be 1024 bytes? SSH version 2 requires at least 768 bytes.

I know how to manually generate a larger key for SSH but doing that breaks any existing certs obtained via MSCEP.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Marcin Latosiewicz Fri, 07/09/2010 - 16:01

I think you're mistaking two parts. SSH v2 requires RSA keys to be 768 (or up). SSH does not rely on certificates.

You can generate RSA keys with a particular label and use them for SSH.

As far as I remember trustpoint CLI will allow you to put a RSA keys label there.


edit: That being said you can generate keys before enrollment and set modulus to 1024 for example.

darthnul Fri, 07/09/2010 - 18:04

SSH does not use certificates but it does use an RSA keypair that I believe the router refers to as "mypubkey" or something like that. If I manually generate an RSA key of 1024 bits for SSH and then do a "ip ssh version 2" command, SSH works fine and only responds (only) to SSH V2 requests. This is what I need to comply with our security standards

But if that is in place when I request a certificate from my CA via MSCEP, a 512 bit key is auto-generated during the request and the new cert is retrieved. The new 512 bit key then seems to become the new "mypubkey" and the SSH daemon restarts, spews a message that it is running version 1.5 and that I need to generate a new larger key if I want version 2. It even removes the "ip ssh version 2" command from my running-config.

If I then generate a larger, self-signed key just for SSH V2, my VPN authentication certifcate breaks.

I think this could be solved by either:

forcing SSH to use a keypair with a specific name

forcing an MSCEP cert request to use an existing named key, or the existing "mypubkey" or

by configuring a default key size for keys that get auto-generated during MSCEP requests

If you know how to achieve any of the above, I'd appreciate a hint.

darthnul Fri, 07/09/2010 - 18:18

OK, I figured out how to generate and specify a specific key pair of adequate modulus just for use by SSH, but I

'd still like to see my VPN identity certificate key be bigger than 512 bits...

darthnul Fri, 07/09/2010 - 20:36

Replying to myself yet again...

It looks like th "rsakeypair" command in the trustpoint cli allows a key size specification which leads me to believe the labeled key doesn't need to be pre-generated. That would be nice, especially if I want to gen new keys at certificate renewal time. It would also not add to the number of interactive commands needed to config a production router which really helps since the configs will get loaded by relatively unskilled technicians. They can handle copy and paste, and file copy stuff but they tend to mess up at least one (of only two) required interactive commands about 10% of the time.

I'll have to do some more playing around with this in my lab at work because I have no plans to add a CA to my home lab...

Marcin Latosiewicz Sat, 07/10/2010 - 02:21

Sorry for this I was replying late at night my time.

Here is what I meant:

DynamicL2L#sh cry key mypubkey rsa
% Key pair was generated at: 09:13:23 CET Jul 10 2010
Key name: SSHKEY
Storage Device: not specified
Usage: General Purpose Key
Key is not exportable.
Key Data:
  30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00AC4935
  267A8B73 7C3C66B2 7F1C92D9 D3185D96 CB8F9AFC C50B4B43 9D84673A 97AF1E38
  95C67925 081A0C59 CC955201 3DDC6CBF E4339EE7 706D1208 F475332C 415E65DD
  1F0B4D09 54A78B5C 6CC4EAFC 7E5F7E85 09E188B4 7CBA7ED0 5C09D06D 7C098D1A
  6D54C260 D5267D6D F3587BD6 12EDD971 27E458AC C3051BB5 AD13DDA4 BB020301 0001
% Key pair was generated at: 09:13:23 CET Jul 10 2010
Key name: SSHKEY.server
Temporary key
Usage: Encryption Key
Key is not exportable.
Key Data:
  307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00C6BB11 178ED2A1
  AECA9E1F F1E941FE 211D55A2 66B79844 9152FC6A 85A7D659 08C3E4B6 C1C5F85F
  53313116 663DDAD0 0293A771 C88DE977 139717EF 66822EAF 13DB6D11 3B7682C8
  BD5F9AFD 476D21E3 893991AF 06286D5D 2D890BE7 F0B2FE45 4D020301 0001
% Key pair was generated at: 09:14:37 CET Jul 10 2010
Storage Device: not specified
Usage: General Purpose Key
Key is not exportable.
Key Data:
  30820122 300D0609 2A864886 F70D0101 01050003 82010F00 3082010A 02820101
  008CC343 7C1CA6C6 9394015C 7611682E 29A44361 36BE7FC9 0F5D06C1 8BC90DA2
  22584D05 7D6A1D2C 6421190F 4C185586 9050396F 07039BB3 DC4EDBD0 A6BFC5C6
  F09C3A81 C886A6B4 764638BE 92407C1F 3865B223 572B7A13 D26EC0A0 484BBB4F
  AEB3C227 BD9B96D9 AD34F2DD 63A6360A A99EFD87 66C6AAAF BAB5A8B5 372E5EEF
  1BCF0C9E CBE03F5B 62D42E43 FF054619 8DB3A43D 377B7708 3F2AB917 31D89C83
  93A18D17 7B2537FF 795C3460 76EF4C2E C39D1ED7 469C823E A518B590 915C7DC6
  753C4533 CF747FAA BB8B9F06 1A8E2CA3 B9384E5A 14E1AC6A 59FFAF3A ED8B7BFF
  F9A44146 261BD562 29D8E3A5 8AE17A99 2989A26C CF2821AA 84FB73A8 BC9317B7
  B1020301 0001

DynamicL2L#sh run | i key|pki

crypto pki trustpoint TESTPOINT
rsakeypair TRUSTPOINT

ip ssh rsa keypair-name SSHKEY

I would need to have a close look at any of my labs but I don't believe enrollment process with SCEP/MSCEP should generate a new key if one already exists (might be version specific).

Please note that IOS CA is quite a decent CA and can do SCEP If you're concenrned about setting up quick testing solution.

darthnul Sat, 07/10/2010 - 11:49


My obsevation has been that SSH will, by default, use an existing key if it can find one, but will never auto-generate a key.

An MSCEP cert request that does not include a key name, will auto-generate a 512 bit key. I have never seen a cert request use an existing key unless it was  specifically configured to do so.

The safe play seems to be to label all keys and specify the size every time.

I have played around a bit with the IOS CA. It's very simple and it does work but I've got an MS CA in the existing infrastructure at work. My goal here is not so much to get a config working (I've already done that). I'm trying to refine the router staging process so relatively unskilled people can load configs on to a thousand or so routers. The fewer interactive things they need to do (like generating an RSA key at the command line) the better the results are likely to be. Right now the only interactive commands they use are "crypto ca authenticate MyCA" and "crypto ca enroll MyCA". They do have to paste in the one-time SCEP challenge password and that's about as far as I want to push them.

If I could figure out a way to install certs without interactive commands, or spending $80 per router for USB tokens I'd be doing that instead.

                    Thanks for your help!   ...jgm


This Discussion

Related Content