I am stuck on a issue. I have DMVPN environment and I am in the process of changing domains and thus new certs and cert servers. I set up my Web server as my SCEP request handler (this is a Microsoft CA subordinate that handles the "NDES/MSCEP" cert publishing, and all is good. I established the new trust point on all my routers and authenticated them, again so far so good. Enrollment is where I am seeing a issue. I have no issue enrolling older equipment (2821, 3845, 1941, 2911, ect) most with ios 15.0, but I cant enroll any of my 4321's running 15.5 is this a bug?
The enrollment request goes through, and the CA issues the cert, the router can see the cert was issued:
CRYPTO_PKI: status = 100: certificate is granted
note:I can see the certificate as issued in my CA as well.
The PKCS#7 message contains 1 cert and 0 crls.
Newly-issued Router Cert: issuer=cn=xxxxxx ,dc=xxxxxx ,dc=com serial=xxxxxxxxxxxxxx
start date: 14:50:30 EST Aug 6 2018
end date: 15:00:30 EST Sep 6 2018
router date: 15:00:56 EST Aug 6 2018
********************** AND THIS IS WHERE I FIRST SEE A ISSUE********
PKI: Router cert issuer mismatch
CRYPTO_PKI: status = 65535: Could not extract router cert or crl from certrep,
CRYPTO_PKI: status = 65535: Failed to process the inner content
%PKI-6-CERTFAIL: Certificate enrollment failed.
I have searched around but can seem to find that "cert issuer mismatch" complaint anywhere. I would think its something with the router not liking that the CA certificate it gets during the authentication step, is not the CA that is trying to issue the certificate, since authentication would get you the Root CA's public, and not the subordinate, or Issuing CA in this case, but I don't have a issue with the other routers I have enrolled just my newer 4321's. Any help would be appreciated, I am guessing I need to enabled something or add a command to the trustpoint settings?
... View more
You have missed the Dialer interface... the Cell0/1/0 interface needs to be looked like a modem... so you need a dialer interface. I also noticed in your Chat-script up i have ATDT*99, were I use 98, not sure if that maters or not. Now you carrier might register your SIM to the SN, or (EIME, MEIE, IEME whatever it is) so the SIM might not come up on the network when switching it to a differant hardware for data traffic. I have this issue with AT&T often. Anyway here is a config similar to yours that I use often: multilink bundle-name authenticated ! chat-script gsm "" "ATDT*98*2#" TIMEOUT 60 "CONNECT" ! ! interface Cellular0/1/0 no ip address ip nat outside ip virtual-reassembly encapsulation ppp dialer in-band dialer pool-member 1 dialer-group 1 no peer default ip address async mode interactive ppp chap hostname ISP@CINGULARGPRS.COM ppp chap password 7 15312222231F07051A62 ppp ipcp dns request fair-queue 64 16 0 ! ! interface Dialer1 ip address negotiated ip access-group 120 in ip nbar protocol-discovery ip nat outside ip nat enable ip virtual-reassembly dialer pool 1 dialer idle-timeout 0 dialer string gsm dialer persistent dialer-group 1 no cdp enable ! ip route 0.0.0.0 0.0.0.0 Dialer1 ! ! control-plane ! ! ! line con 0 login local line aux 0 line 0/1/0 exec-timeout 0 0 script dialer gsm login modem InOut no exec transport input all rxspeed 3600000 txspeed 384000 line 67 no activation-character no exec transport preferred none transport input all transport output pad telnet rlogin lapb-ta mop udptn v120 ssh stopbits 1 As you can see you default to the dialer interface not the cell interface. the Dialer acts as the middle man determining when the cell should make the connection and when not. As you see I have mine set to be up all the time with the "Dialer persistent" cammand. if using this as a back up data connection you will want to use on demand dialing with a acl.... keeping the connection up all the time even not passing traffic, just in a idle state, will take you over you contracted 5Gig bandwidth. It is not realy unlimited data, so read the fine print. I think Sprint has a true unlimited plan for this use, but the odds of having service is about as commen as everyone having a lake front home... Good luck.. Dave P.S. I just noticed you are not using US cell service so just ignore my carrier specific comments... use your APN not what I have listed...
... View more
So I found some time to open up the new 1941ISR's I am supose to be testing for the field. I am having hellish DMVPN issues but I will post about that later. I am confused, lost, or just missdirected on the PoE and PfR functions of the 1941 or 15.0.1M4 IOS I have no PfR, OER, or PoE commands in my CLI For example the OER or PfR issue: Edge1941-201# Edge1941-201#config t Enter configuration commands, one per line. End with CNTL/Z. Edge1941-201(config)#oer ? % Unrecognized command Edge1941-201(config)#pfr ? % Unrecognized command Edge1941-201(config)#o? object-group Edge1941-201(config)#p? parameter-map parser password policy-manager policy-map ppp printer priority-list privilege process process-max-time prompt Edge1941-201(config)# As you can see above, no OER, or PFR commands are in the global config, where did they go? The docs say the new 15.0 IOS support EIGRP route injection with PfR and DMVPN. but when you read to set it up it states a prereq is to have OER functioning on the router? Some help on how to get it working with no syntacs would be helpfull... Now the inline power issue: Edge1941-201#sh po? policy-manager policy-map Edge1941-201#config t Enter configuration commands, one per line. End with CNTL/Z. Edge1941-201(config)#po? policy-manager policy-map Edge1941-201(config)# as you can see I have no "Sh inline power" command, or any other inline PoE commands weather in the interface config or global? Its great I have the PoE power supplies with no command line to turn the function on for my PoE ether card. I am guessing I was not paying attention during the evolution that took place between 12.4 and 15.0 so any help pointing me in the right direction would be great. if I get some help I might just even post my latest DMVPN issue, or lack of DMVPN I should say. This is more of a IPsec/crypto issue on the 1941, but again for another time. Sorry if I sound cranky, but I am. Leave it to Cisco to screw up my week.... Thanks, Dave
... View more