I’ve been doing a lot of PKI work over the last few days, testing device enrollment and NDES etc, and came across this problem being logged on my issuing/subordinate CA server;
Log Name: Application
Source: Microsoft-Windows-CertificationAuthority
Event ID: 53
Task Category: None
Level: Warning
Keywords:
User: SYSTEM
Description:
Active Directory Certificate Services denied request 35 because The public key does not meet the minimum size required by the specified certificate template. 0x80094811 (-2146875375 CERTSRV_E_KEY_LENGTH). The request was for SERIALNUMBER=4279256517 + OID.1.2.840.113549.1.9.2="sprugal.testbench.local ". Additional information: Denied by Policy Module Resubmitted by TESTBENCHAdministrator
Solution
In addition on the server itself in the Certification Authority Management console, under failed requests, it was showing the same error;
By default the certificate that NDES / MSCEP used as a template for your network devices is called ‘IPSec (Offline request)’ I’ve cloned that and made my own called NDESTemplate, but if you take a look on the Cryptography tab you can see that the minimum key size is set to 1024.
The network devices that are attempting to enroll with my server must have a key-length that is shorter, how can you tell? Well my devices are all Cisco ones (Routers and Firewalls). The Cisco ASA will tell you what key length is uses, but there is no command in router IOS to let me know. However if you use Putty and open an SSH session to the device it will tell you.
In the example below, the key length on this device is 2048 so that should be fine;
But this one is only 768 bits long! This device would generate the sort of errors I’m seeing on my Windows server.
So how do you fix the problem on the device, if you have not got your trustpoint setup then simply issue the following commands;
[box]
R1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#crypto key zeroize rsa
% All RSA keys will be removed.
% All router certs issued using these keys will also be removed.
Do you really want to remove these keys? [yes/no]: yes
R1(config)#
*Jul 11 14:26:50.619: %SSH-5-DISABLED: SSH 1.99 has been disabled
R1(config)#
[/box]
If you have setup a trustpoint, simply remove the trustpoint and it removes all the keys
[box]
R1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#no crypto pki trustpoint PNL-TRUSTPOINTNOTE YOUR TRUSTPOINT WILL HAVE A DIFFERENT NAME!!
% Removing an enrolled trustpoint will destroy all certificates
received from the related Certificate Authority.
Are you sure you want to do this? [yes/no]: yes
% Be sure to ask the CA administrator to revoke your certificates.
No enrollment sessions are currently active.
R1(config)#
[/box]
Related Articles, References, Credits, or External Links
Later on in the year I’ve got a big RSA and SharePoint deployment, as I know ‘Zippity Squat’ about SharePoint, I thought the best way to get some hands on experience, was to work out how to integrate SecureID with Exchange 2013, (which I know a few things about!)
Solution
I’m assuming you already have RSA Authentication Manager setup and users/tokens deployed. This run though is simply to get your RSA solution working with Exchange/OWA
1. Create a user in Active Directory, (here I’m using SVC_RSA_Access), and ensure that user has a mailbox, you can do this in the Exchange Admin Center, but I prefer to use the shell.
6. We need to have the .Net 3.5 Feature added. (Server Manager > Add Roles and Features).
7. Log onto the Security Console of your RSA Authentication Manager appliance > Access > Authentication Agents > Generate Configuration File > Follow the wizard > Download the file.
8. Place the file you downloaded (sdconf.inf) on the Exchange server in the C:Windowssystem32 folder.
9. Download and install the RSA Authentication Agent for Web for IIS, Install and accept all the defaults, it should locate the config file you have just downloaded.
10. On the Exchange server launch ‘RSA Web Agent’, and don’t be surprised when IIS Manager opens.
Not the most descriptive of errors! In fact this has got nothing to do with the busyness of the web server at all.
Solution
What’s actually happening is the RSA agent on this machine (in this case a web server) cannot communicate with the RSA Authentication Manager. In my case the web server was in a DMZ, and the RSA Authentication Manager Appliance was in another DMZ. The ports required (TCP 5500, UDP 5500, and TCP 5580). were not open from the agent to the appliance. Once I fixed that, we were up and running.
Related Articles, References, Credits, or External Links
It’s been a while since I had to do this, you used to simply take a number from the token pack, import it into the RSA Authentication Manager, job done. Now the tokens are shipped to you encrypted, you need to register them with RSA, decrypt them, then import them.
Solution
1. The tokens come with the licenses encrypted, on an accompanying CD. Go to the URL specified on the CD.
2. Good job I was alone and had no CD drive! Anyway the two numbers you need to enter on the website to register are;
Token Pack ID: On the sleeve, and on the CD
Confirmation Number : On the CD
3. When you have finished registration you will download a .zip file, save it somewhere sensible.
4. Put the CD in a computer > Run the ‘Run the Token Decryption Utility’ > You will need to give it the .zip file you downloaded and a password.
5. When complete, you will be given two files, an XML file that has all your token information.
6. And a password file, that gives you a password to import the XML file with.
7. Armed with these two files log into the ‘Security Console’ > Administration > SecureID Tokens > Import Tokens Job > Add New.
8. Give the job a name accept all the defaults and browse to the XML file, then copy and paste in the password form the text file and run the import job. Check on the completed tab to make sure it was a success.
Related Articles, References, Credits, or External Links
As with most things, before you have a hope of fixing something, you will stand a better chance if you know how it works in the first place. Below is a quick run though of what’s happening with your site to site VPN‘s and how they work.
For the entire process we will have two Cisco ASA 5500 firewalls and a site to site VPN.
Solution
What’s an Initiator and a Responder?
1. Our Laptop 192.168.1.50 wants to talk to a server on the other site at 172.16.1.50
2. To get out of the local network the Laptop goes through the ASA at its local site, The ASA knows that traffic destined for 172.16.1.50 needs to be sent down the VPN tunnel, so it needs to bring up the tunnel. IT BECOMES THE INITIATOR, contacts the ASA on the other site THAT BECOMES THE RESPONDER.
3 Once that’s complete the tunnel is up and traffic can pass.
So how does it bring up the Tunnel?
To establish an ISAKMPVPN tunnel 3 things have to happen.
1. Phase 1 has to complete.
2. Phase 2 has to complete.
3. The Traffic has to be allowed to pass.
VPN Phase 1 (ISAKMP)
This stage brings up the first secure tunnel (eventually there will be three tunnels) and for it to establish the firewalls need to agree what they are going to do to bring up the tunnel, then Secure the tunnel. This process uses SIX MESSAGES (Note: We are dealing to Main Mode here not Aggressive mode). Both firewalls need a matching Phase 1 Policy to continue. And the Policy is proposed in MESSAGE1 and accepted in MESSAGE2.
A Phase 1 policy consists of,
1. The Authentication method (either a pre shared key or an RSA signature is usual).
5. Lifetime (In seconds before phase 1 should be re-established – usually 86400 seconds [1 day]).
MESSAGE 1
The Initiator sends policies that it proposes to use, for phase 1 to the other ASA.
MESSAGE 2
Providing the responder has a matching policy it will accept one of those proposed by the initiator and send it back in message 2.
Now the two ends have agreed HOW they will establish phase 1, they then need to agree on a “Shared Key” both ends must use the same shared key, but the shared key cant be sent between them because the network link is not secure. To do this they use a Diffie Hellman key exchange, this uses a mathematical process called modular exponentiation, a simple example of how that works (The math’s involved in a real key exchange are much more complicated!).
How Diffie Hellman works (simply)
Problem Site A and Site B need to use the same secret key (which will be a big long number). they cant send that number to each other because if they do it will be seen.
Solution:
Both sites pick a random number, and they have a common number, this common number can be passed between sites, In our example Site A chooses 4 and Site B chooses 5
Both sites use the common number and raise it by the power of the random number they are using so Site A arrives at 16, and Site B at 32.
The sites then send the number they have arrived at, to the other site.
Each site uses the other sites total and raises it to the power of their original random number, this results in them both having the same key, with only the numbers 2, 16 and 32 being passed between them.
Back to our VPN Tunnel
The next two messages are the initiator and responder swapping their Diffie Hellman information, Each side produces a DH Public Key, and mathematically computes a long number called a “Nonce”
MESSAGE 3
The initiator generates a “Public Key” also called the DH Public Value or Xa It also generates a Nonce or Ni and sends both of them to the responder.
MESSAGE 4
The responder generates a “Public Key” also called the DH Public Value or Xb It also generates a Nonce or Nr and sends both of them to the initiator.
At this point both the initiator and the responder can calculate the DH Shared secret key, they then use the DH Secret Key, the “Shared Secret” that is manually entered onto both peers, and the Nonce from the other peer to create 3 DIGITAL KEYS, because of the nature of Diffie Hellman each end will produce the same keys.
Key 1 = SKEYID_d Used to work out any future IPsec keying Key 2 = SKEYID_a Used for data integrity and authentication (IKE) Key 3 = SKEYID_e Used to encrypt all further IKE traffic.
MESSAGE 5
The initiator now sends its ID to the responder (this is either its IP address or a hostname). It also sends a “Hash” this authenticates the initiator to the responder as its made from the SKEYID, the pre-shared key and other information only known to the two peers.
MESSAGE 6
Message 6 is basically the mirror of Message 5, the responder sends its ID (IP or Hostname) Back the the initiator with its “Hash” and authenticates itself back to the initiator.
At this point both peers recalculate the hash they have received from the other peer, and they should both come out the same, if this happens then the IKESA’s are established and phase 1 is complete.
So what’s PFS?
Perfect Forward Secrecy is a method by which new keys are generated, each new key is mathematically linked to the key that came before it, the prior key being a “Grandfather” key. With PFS enabled this link is broken so a key can not be forward/reverse engineered to guess a previous/new key value). Every new negotiation produces a new fresh key.
Once Phase 1 has completed the second stage of the VPN can start. Like phase 1 this state also requires messages to be sent between the peers, IPsec usually executes in “Quick mode” this means that there are only 3 MESSAGES.
Note: If PFS is configured only on one end then it will fail at this point with an “Attribute not supported” error.
MESSAGE 1
The Initiator sends another Hash to the responder, this is similar to the one used in phase 1 but also includes info within this message to guarantee integrity.
4. The SPI – This number is the LABEL for the end of the tunnel the initiator will use for outbound traffic.
Tunnel mode (Tunnel or Transport). A timeout in seconds is specified, as is the ID (usually the subnet of both ends of the tunnel).
MESSAGE 2
The Responder replies with its own “Hash” with the accepted proposal and its own SPI for outgoing encrypted traffic from the responder, and finally its own Key Exchange Payload.
Once this is complete both peers generate new DH secret keys and combine them with the SKEYID_d key from phase 1 to create keys for IPsec encryption.
MESSAGE 3
The final Message is sent from imitator to responder, and serves to inform the responder that its previous message was received.
Once phase 2 is complete IPsec SA’s have been established and the tunnel is up.
Related Articles, References, Credits, or External Links
