Cert help needed, to get cisco VPN clients working

Question

Hi folks, I need help getting some cisco clients connected to my UTM. Specifically these are iPads with a cisco IPsec profile on them. Basically, I'm really bad with certificates. I do not understand why this isn't working. I'll throw in some screenshots too. 
 
 Here's what I did: 
 
 1. Generate new cert in the UTM, all default settings with just my country, city, and org in it. 2048 bit keysize, VPN ID: Distinguished name.

2. Create a new local user in the UTM. 
 
 3. Set this user's authentication cert as the one I just generated.

4. Head into remote access -> cisco VPN client. Set it to my wan interface, server certificate is the local x509 cert (default). Selected my desired LAN devices, and put that new user into the users and groups. AUTO firewall rules ON.

5. Download that generated cert from the utm.

5. Create new profile for iPad in my MDM, tell it to connect to my wan IP. set the username.

6. Upload the cert to the ipad, tell it to use that for authentication.

So, to summarize: there are two certificates in play here. One, the serverside cert, which is the default x509. The other, which is a cert I manually generated, is pushed to the ipad. 
 
 when I attempt to connect with the iPad, it fails to connect with the error: "Could not validate the server certificate" 
 
 and here is the livelog :

2019:02:25-15:06:16 utm-2 pluto[8684]: packet from 174.224.20.149:8419: received Vendor ID payload [RFC 3947]
2019:02:25-15:06:16 utm-2 pluto[8684]: packet from 174.224.20.149:8419: ignoring Vendor ID payload [4df37928e9fc4fd1b3262170d515c662]
2019:02:25-15:06:16 utm-2 pluto[8684]: packet from 174.224.20.149:8419: ignoring Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
2019:02:25-15:06:16 utm-2 pluto[8684]: packet from 174.224.20.149:8419: ignoring Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
2019:02:25-15:06:16 utm-2 pluto[8684]: packet from 174.224.20.149:8419: ignoring Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
2019:02:25-15:06:16 utm-2 pluto[8684]: packet from 174.224.20.149:8419: ignoring Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
2019:02:25-15:06:16 utm-2 pluto[8684]: packet from 174.224.20.149:8419: ignoring Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
2019:02:25-15:06:16 utm-2 pluto[8684]: packet from 174.224.20.149:8419: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
2019:02:25-15:06:16 utm-2 pluto[8684]: packet from 174.224.20.149:8419: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
2019:02:25-15:06:16 utm-2 pluto[8684]: packet from 174.224.20.149:8419: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
2019:02:25-15:06:16 utm-2 pluto[8684]: packet from 174.224.20.149:8419: received Vendor ID payload [XAUTH]
2019:02:25-15:06:16 utm-2 pluto[8684]: packet from 174.224.20.149:8419: ignoring Vendor ID payload [Cisco-Unity]
2019:02:25-15:06:16 utm-2 pluto[8684]: packet from 174.224.20.149:8419: ignoring Vendor ID payload [FRAGMENTATION 80000000]
2019:02:25-15:06:16 utm-2 pluto[8684]: packet from 174.224.20.149:8419: received Vendor ID payload [Dead Peer Detection]
2019:02:25-15:06:16 utm-2 pluto[8684]: "D_for ipad to daniel-lt-3"[10] 174.224.20.149:8419 #371: responding to Main Mode from unknown peer 174.224.20.149:8419
2019:02:25-15:06:16 utm-2 pluto[8684]: "D_for ipad to daniel-lt-3"[10] 174.224.20.149:8419 #371: NAT-Traversal: Result using RFC 3947: peer is NATed
2019:02:25-15:06:16 utm-2 pluto[8684]: | NAT-T: new mapping 174.224.20.149:8419/8439)
2019:02:25-15:06:16 utm-2 pluto[8684]: "D_for ipad to daniel-lt-3"[10] 174.224.20.149:8439 #371: ignoring informational payload, type IPSEC_INITIAL_CONTACT
2019:02:25-15:06:16 utm-2 pluto[8684]: "D_for ipad to daniel-lt-3"[10] 174.224.20.149:8439 #371: Peer ID is ID_DER_ASN1_DN: 'C=us, L=omitted, O=omitted, CN=ipad'
2019:02:25-15:06:16 utm-2 pluto[8684]: "D_for ipad to daniel-lt-3"[10] 174.224.20.149:8439 #371: crl not found
2019:02:25-15:06:16 utm-2 pluto[8684]: "D_for ipad to daniel-lt-3"[10] 174.224.20.149:8439 #371: certificate status unknown
2019:02:25-15:06:16 utm-2 pluto[8684]: "D_for ipad to daniel-lt-3"[5] 174.224.20.149:8439 #371: deleting connection "D_for ipad to daniel-lt-3"[10] instance with peer 174.224.20.149 {isakmp=#0/ipsec=#0}
2019:02:25-15:06:16 utm-2 pluto[8684]: "D_for ipad to daniel-lt-3"[5] 174.224.20.149:8439 #371: we have a cert and are sending it
2019:02:25-15:06:16 utm-2 pluto[8684]: "D_for ipad to daniel-lt-3"[5] 174.224.20.149:8439 #371: Dead Peer Detection (RFC 3706) enabled
2019:02:25-15:06:16 utm-2 pluto[8684]: "D_for ipad to daniel-lt-3"[5] 174.224.20.149:8439 #371: sent MR3, ISAKMP SA established
2019:02:25-15:06:16 utm-2 pluto[8684]: "D_for ipad to daniel-lt-3"[5] 174.224.20.149:8439 #371: sending XAUTH request
2019:02:25-15:06:16 utm-2 pluto[8684]: packet from 174.224.20.149:8439: Informational Exchange is for an unknown (expired?) SA
2019:02:25-15:06:26 utm-2 pluto[8684]: ERROR: asynchronous network error report on eth2 for message to 174.224.20.149 port 8439, complainant 174.224.20.149: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]
2019:02:25-15:07:26 utm-2 pluto[8684]: "D_for ipad to daniel-lt-3"[5] 174.224.20.149:8439 #371: max number of retransmissions (2) reached STATE_XAUTH_R1
2019:02:25-15:07:26 utm-2 pluto[8684]: "D_for ipad to daniel-lt-3"[5] 174.224.20.149:8439: deleting connection "D_for ipad to daniel-lt-3"[5] instance with peer 174.224.20.149 {isakmp=#0/ipsec=#0}

Why do you think it isn't working? Thank you!

BAlfson · Accepted Answer

I'll be back later for the main issue in this thread, but, yes 9.601 does fix the bug. In the meantime, Modify a certificate at the command line so that it can be downloaded in WebAdmin in 9.510 . 
 Cheers - Bob

Daniel Avrit · Answer

thanks so much for this, my google searches did not turn that up. I renamed the user cert, downloaded it, and pushed it out to the iPad, which replaced the manually generated usercert that I was using before. 
 
 I also changed the server cert to an externally signed (by a CA service we use) certificate that matched the hostname that the iOS device was connecting to. Apparently that's a requirement, I was having the iPad connect to our direct IP before. That's a no-no. 
 
 I'm not sure which change fixed it, but it lit right up. You're a lifesaver! I'll mark this as solved.

DouglasFoster · Answer

When you create a local user, UTM creates (generates) a certificate for the user, and adds it to the user account. This is the one that you want to push out. For your description, it sounds like you pushed out the root certificate. 
 === 
 Short summary of certificate theory. (It is easiest to explain using an https web connection as the example.) 
 You ask for a web site. DNS (or a HOSTS file) turns the name into an IP address. You rely on multiple routers and firewalls to get the packet to the right place, and the reply back to you. That process can be corrupted by malicious name-to-address translation, by malicious NAT address changes, by malicious routing, or by malicious packet interception. It may not happen often, but the process is designed for the worst-case scenario. 
 For encryption to be meaningful, you have to be talking to the right party. So https requires the server to send back an identity certificate. Your browser compares the name on the certificate to the name you requested. If they do not match, you do not have a trusted connection. 
 But it gets trickier. Anybody can claim to be anything, so we need a way to decide what certificates to trust. At the airport, they accept a government-issued ID. They do not accept your insurance card or your (non-government) work badge. The same applies here. An identity certificate has to be signed by an intermediate certificate, which has to be signed by a root certificate. What makes the root certificate trusted is that you (or somebody) chose to install it on your PC! You trust that certificates signed by that root are legitimate. 
 Since root certificates are installed on your PC, there is no way to revoke them. Intermediate certificates are used so that large masses of certificates can be revoked at once, if necessary. Not likely to ever happen. There can be no intermediate certificate, or more than one. The requirement is that the certificate chain ends with a certificate installed on your PC with a "root" status assigned to it. 
 For the web, certificates are usually used for server authentication only. It is perfectly possible for the server to ask you for a certificate to prove your identity as well, and your certificate better be signed by somebody the server trusts. Depending on the security purpose, a client can be identified with a device certificate or a user certificate. Site-to-site VPN tunnels can validate a remote device using a device certificate. Client VPN connections would typically use a user certificate. 
 ==== 
 I have not used Cisco VPN client with UTM. For UTM's SSL VPN client configuration, UTM has its own root, and issues user certificates against that root. When the user connects back to that UTM, the UTM honors the client certificate because it was issued by its own root. It think the Cisco client may work in a very similar way.