Good Afternoon,

I have ikev2 setup with a trusted third party CA based certificate on the routerboard and the radius server (nps 2016) and it works fine with iPhones without the need to install any certificates on the ios device. I'm using eap radius pass through and it all works great. However no matter what i try i cannot get windows 10 clients to connect.

Windows 10 comes back with error 13801 in the event log and "IKE authentication credentials are unacceptable" when trying to connect.

The certificate were using is a commodo cert its valid for vpn.xxx.xxx and in the subject alt name also have DNS: vpn.xxx.xxx

Were using mode-config to pass ip / dns down to the clients.

Has anyone managed to get eap-radius working with windows 10 clients.

Many Thanks

From further investigation it does seem to be certificate related

Test 1:
On the router board i generated a ca, server cert, client cert, i imported the ca and client cert into the machine store and changed from eap radius to certificate based auth and the connection worked.

Test 2:
I then flicked the config back to using eap radius and used the server cert i had generated on the router board. Since the client had the ca in the trusted store the connection was successful.

Conclusion:
When using a third party certificate the connection fails with error 13801 on windows (IKE Authentication credentials are unacceptable) and the error logs on the router board don't show anything at the point it fails baring sending x bytes to xxx.xxx.xxx.xxx.

I've tried comodo and rapidssl certificates, I've tried with and without the full chain being imported into the routerboard and still the same error.

Any help would be appreciated, or if someone can confirm they have had it working with third party certs.
Thanks

Martin.

If it works with self signed and does not work with cert provider certs, then you simply did not install full cert chain.

Really appreciated the response on this...

So when i'm importing the certificates in this instance i follow this procedure.

I've tried these scenarios:
- I import the chain in 1 file listed below, i then import the server certificate vpn.xxx.xxx and then i import the private key.
- i import the chain and server certificate in 1 file and then i import the private key.

Neither of these work, i do note that the root ca cert don't show as CA's in the certificates screen against the server certificate.

The server certificate is issued by "COMODO RSA Domain Validation Secure Server CA" which is the starting point of the chain all the way up to the add trust root.

is there a different procedure i should follow for importing the full chain?



-----BEGIN CERTIFICATE-----
MIIGCDCCA/CgAwIBAgIQKy5u6tl1NmwUim7bo3yMBzANBgkqhkiG9w0BAQwFADCB
hTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNV
BAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTQwMjEy
MDAwMDAwWhcNMjkwMjExMjM1OTU5WjCBkDELMAkGA1UEBhMCR0IxGzAZBgNVBAgT
EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxNjA0BgNVBAMTLUNPTU9ETyBSU0EgRG9tYWluIFZh
bGlkYXRpb24gU2VjdXJlIFNlcnZlciBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAI7CAhnhoFmk6zg1jSz9AdDTScBkxwtiBUUWOqigwAwCfx3M28Sh
bXcDow+G+eMGnD4LgYqbSRutA776S9uMIO3Vzl5ljj4Nr0zCsLdFXlIvNN5IJGS0
Qa4Al/e+Z96e0HqnU4A7fK31llVvl0cKfIWLIpeNs4TgllfQcBhglo/uLQeTnaG6
ytHNe+nEKpooIZFNb5JPJaXyejXdJtxGpdCsWTWM/06RQ1A/WZMebFEh7lgUq/51
UHg+TLAchhP6a5i84DuUHoVS3AOTJBhuyydRReZw3iVDpA3hSqXttn7IzW3uLh0n
c13cRTCAquOyQQuvvUSH2rnlG51/ruWFgqUCAwEAAaOCAWUwggFhMB8GA1UdIwQY
MBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSQr2o6lFoL2JDqElZz
30O0Oija5zAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNV
HSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwGwYDVR0gBBQwEjAGBgRVHSAAMAgG
BmeBDAECATBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNv
bS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcB
AQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9E
T1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21v
ZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAE4rdk+SHGI2ibp3wScF9BzWRJ2p
mj6q1WZmAT7qSeaiNbz69t2Vjpk1mA42GHWx3d1Qcnyu3HeIzg/3kCDKo2cuH1Z/
e+FE6kKVxF0NAVBGFfKBiVlsit2M8RKhjTpCipj4SzR7JzsItG8kO3KdY3RYPBps
P0/HEZrIqPW1N+8QRcZs2eBelSaz662jue5/DJpmNXMyYE7l3YphLG5SEXdoltMY
dVEVABt0iN3hxzgEQyjpFv3ZBdRdRydg1vs4O2xyopT4Qhrf7W8GjEXCBgCq5Ojc
2bXhc3js9iPc0d1sjhqPpepUfJa3w/5Vjo1JXvxku88+vZbrac2/4EjxYoIQ5QxG
V/Iz2tDIY+3GH5QFlkoakdH368+PUq4NCNk+qKBR6cGHdNXJ93SrLlP7u3r7l+L4
HyaPs9Kg4DdbKDsx5Q5XLVq4rXmsXiBmGqW5prU5wfWYQ//u+aen/e7KJD2AFsQX
j4rBYKEMrltDR5FL1ZoXX/nUh8HCjLfn4g8wGTeGrODcQgPmlKidrv0PJFGUzpII
0fxQ8ANAe4hZ7Q7drNJ3gjTcBpUC2JD5Leo31Rpg0Gcg19hCC0Wvgmje3WYkN5Ap
lBlGGSW4gNfL1IYoakRwJiNiqZ+Gb7+6kHDSVneFeO/qJakXzlByjAA6quPbYzSf
+AZxAeKCINT+b72x
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFdDCCBFygAwIBAgIQJ2buVutJ846r13Ci/ITeIjANBgkqhkiG9w0BAQwFADBv
MQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFk
ZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBF
eHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFow
gYUxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYD
VQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIICIjANBgkq
hkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAkehUktIKVrGsDSTdxc9EZ3SZKzejfSNw
AHG8U9/E+ioSj0t/EFa9n3Byt2F/yUsPF6c947AEYe7/EZfH9IY+Cvo+XPmT5jR6
2RRr55yzhaCCenavcZDX7P0N+pxs+t+wgvQUfvm+xKYvT3+Zf7X8Z0NyvQwA1onr
ayzT7Y+YHBSrfuXjbvzYqOSSJNpDa2K4Vf3qwbxstovzDo2a5JtsaZn4eEgwRdWt
4Q08RWD8MpZRJ7xnw8outmvqRsfHIKCxH2XeSAi6pE6p8oNGN4Tr6MyBSENnTnIq
m1y9TBsoilwie7SrmNnu4FGDwwlGTm0+mfqVF9p8M1dBPI1R7Qu2XK8sYxrfV8g/
vOldxJuvRZnio1oktLqpVj3Pb6r/SVi+8Kj/9Lit6Tf7urj0Czr56ENCHonYhMsT
8dm74YlguIwoVqwUHZwK53Hrzw7dPamWoUi9PPevtQ0iTMARgexWO/bTouJbt7IE
IlKVgJNp6I5MZfGRAy1wdALqi2cVKWlSArvX31BqVUa/oKMoYX9w0MOiqiwhqkfO
KJwGRXa/ghgntNWutMtQ5mv0TIZxMOmm3xaG4Nj/QN370EKIf6MzOi5cHkERgWPO
GHFrK+ymircxXDpqR+DDeVnWIBqv8mqYqnK8V0rSS527EPywTEHl7R09XiidnMy/
s1Hap0flhFMCAwEAAaOB9DCB8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g
JMtUGjAdBgNVHQ4EFgQUu69+Aj36pvE8hI6t7jiY7NkyMtQwDgYDVR0PAQH/BAQD
AgGGMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMEQGA1UdHwQ9
MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVy
bmFsQ0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6
Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggEBAGS/g/FfmoXQ
zbihKVcN6Fr30ek+8nYEbvFScLsePP9NDXRqzIGCJdPDoCpdTPW6i6FtxFQJdcfj
Jw5dhHk3QBN39bSsHNA7qxcS1u80GH4r6XnTq1dFDK8o+tDb5VCViLvfhVdpfZLY
Uspzgb8c8+a4bmYRBbMelC1/kZWSWfFMzqORcUx8Rww7Cxn2obFshj5cqsQugsv5
B5a6SE2Q8pTIqXOi6wZ7I53eovNNVZ96YUWYGGjHXkBrI/V5eu+MtWuLt29G9Hvx
PUsE2JOAWVrgQSQdso8VYFhH2+9uRv0V9dlfmrPb2LjkQLPNlzmuhbsdjrzch5vR
pu/xO28QOG8=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU
MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFs
IFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0Ux
FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9v
dDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTngTlvt
H7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9
uMq/NzgtHj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzX
mk6vBbOmcZSccbNQYArHE504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LX
a0Tkx63ubUFfclpxCDezeWWkWaCUN/cALw3CknLa0Dhy2xSoRcRdKn23tNbE7qzN
E0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3CitlttNCbxWyuHv77+ldU9U0
WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTLVBowCwYD
VR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0
Jvf6xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRU
cnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx
IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcN
AQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5gdkeWxQHIzZlj7DYd7usQWxH
YINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKWt9x+Tu5w/Rw5
6wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC
Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEX
c4g/VhsxOBi0cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5a
mnkPIAou1Z5jJh5VkpTYghdae9C8x49OhgQ=
-----END CERTIFICATE-----

Most likely it is not the whole chain but only part of it. Take into consideration that if CRL is used, then CRL can be signed by completely different CA chain.

Thanks again for the pointers on this i hadn't checked the CRL signing but have now however all appears to be signed by the same chain as the certificate.

Once i get this working i do intend to post the config and general things I've encountered while getting this setup.

Here is the certificates screen on the routerboard and you can follow the chain through to the addtrust root.



Here is the list of CRLS on the routerboard from the certs



Then here is each of those crls and who has signed them.

COMODORSADomainValidationSecureServerCA.crl
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
Last Update: Jul 20 03:39:19 2018 GMT
Next Update: Jul 24 03:39:19 2018 GMT
CRL extensions:
X509v3 Authority Key Identifier:
keyid:90:AF:6A:3A:94:5A:0B:D8:90:EA:12:56:73:DF:43:B4:3A:28:DA:E7

X509v3 CRL Number:
1693

COMODORSACertificationAuthority.crl

Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: sha384WithRSAEncryption
Issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
Last Update: Jul 19 12:48:07 2018 GMT
Next Update: Jul 23 12:48:07 2018 GMT
CRL extensions:
X509v3 Authority Key Identifier:
keyid:BB:AF:7E:02:3D:FA:A6:F1:3C:84:8E:AD:EE:38:98:EC:D9:32:32:D4

X509v3 CRL Number:
3211
AddTrustExternalCARoot.crl

Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: sha1WithRSAEncryption
Issuer: /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
Last Update: Jul 19 12:48:07 2018 GMT
Next Update: Jul 23 12:48:07 2018 GMT
CRL extensions:
X509v3 Authority Key Identifier:
keyid:AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A

X509v3 CRL Number:
4944

Good Evening,

i've done some more testing and with either Rapid ssl certificates or the Comodo certificates if i import the intermediate certificate into the windows machine personal certificate store the connection is successful.

In the instance of the Comodo certificate i'm importing the "COMODO RSA Domain Validation Secure Server CA certificate". my conclusion is that it would appear that the full chain already has to be present in windows to allow a successful connection. As the certificates further up the chain are included in the windows certificate store as default.

i was under the impression that the certificate chain would be passed from the router board to the windows client? therefore meaning you wouldn't need to install any certs on the client.

can anyone shed any light on this?

Thanks
Martin.

Little More Update:

No real progress however i did notice both intermediates have tls client & tls server in their key usage and obviously my server certificate does also.

I wonder if this is confusing the windows client somehow?

Hi!
Same situation here. I also use Comodo trusted certificate and windows 10 ikev2 cant connect too with the same error.
If I'm not mistake, I think that I have already tested ike2 eap radius on mikrotik with the same trusted certificate and it worked before. Maybe several mounth ago.
Have you tried some RouterOS previous versions? Or have you found any other solution?

In the end i emailed support about the issue and got confirmation that the Mikrotik implementation requires the client to have the full chain present and that the mikrotik side does not pass over intermediates to the client.

Basically on windows you have to install the intermediates, obviously this can be done with group policy or manually if you so wish. in the instance of the comodo certificate i had to import "COMODO RSA Domain Validation Secure Server CA" into the windows computer certificate store.

From my research strongswans ikev2 server on linux has the ability to pass the intermediates to windows clients, would be great if Mikrotik had the ability to do this. In means if your changing cert providers you have to plan a little more carefully.

Hope thats helps.

Thanks for the info!
Thats so sad. We still have no really universal and modern vpn solution for RoadWarriors with mikrotik.
Of course we can add sertificates with goup policy but in this case there's no need to purchase a trusted certificate But what about non-domain PCs? Again we have to write some additional instructions to users regarding installing certificates.
Also I have found a post, where mrz from mikrotik support says, that we do not need to install any certificates on client PC: viewtopic.php?t=122895#p605065
So where is the truth?
Why does everything always work fine on StrongSwan and there are always some drawbacks with mikrotik?
Guys from mikrotik, can you please make at least one vpn technology to work as it should? And I think it should be ikev2.
Thanks!

You do not need to install any certificates if client has proper chain already pre-installed with operating system (for most cert providers that is true).

I cannot tell why Windows do not have all Comodo cert chain, probably you should ask this question either to comodo support or MS support.

Thanks for the reply on this mrz, from what i can tell no intermediates baring one from verisign are included in windows 10 as a default its only the root CA's.

If anyone knows of a certificate authority with reasonably priced certificates that has the full chain present in windows please let me know as i will go with that provider.

From actual testing these CA's require the intermediates to be installed.
comodo
rapidssl

My key point here is it would seem that there isnt any* certificate authority that has the full chain present in windows therefore requiring clients to install the intermediates to add more evidence to this see below for examples of 3 different providers that do not have their intermediates in windows.

i would love to be proved wrong on this one?

From research as examples:
Letsencrypt

DST Root CA X3 (Included in windows)
Let's Encrypt Authority X3 (Not Present)



Digicert

DigiCert Global Root CA (inlcuded in windows)
Digicert SHA2 Secure Server CA (not present)



GoDaddy
Go Daddy Root Certificate Authority - G2 (included in windows)
Go Daddy Secure Certificate Authority - G2 (not present)

We will look into this.

thanks mrz, if you need me to test anything just drop me a line.

v6.44beta version will have new feature:
ike2- option to specify certificate chain

Great news, mrz! I'm really glad you are working on this issue.

But I cannot get it to work. I have installed 6.44beta6 and I cannot find this option. Can you tell me how to configure it? Or maybe it just works automatically?
By the way, now I'm getting some other error when connecting from Windows 10: "The context has expired and can no longer be used".

Sorry, my fault. It seems i was importing certificate private key with wrong password. I have imported it again and went back to the first error: "IKE authentication credentials are unacceptable".
But after some more time I've got it working!

It seems for now we have to use terminal to configure that certificate chain option. Here is an example for Comodo: Of course, your certificate with private key and Comodo's intermediate certificate should be imported to Mikrotik.
I hope this option will be added to winbox soon or maybe with stable firmware release.

Yes, you got it right, initially it is CLI only but will be added to Winbox too.

Is the "certificate" option available in 6.44beta61 ?

It seems like CLI does not recognize this parameter …

[admin@ip-172-31-36-160.eu-west-3.compute.internal] > /ip ipsec peer set certificate=certificate.crt,ca_bundle.crt
expected end of command (line 1 column 31)

After some changes in ipsec configuration you can use a command like this: And it seems that now you can also set a certificate chain using just Winbox GUI.

I have just tested ikev2 eap radius with my comodo certificate on 6.44.1 firmware and it works fine! Thanks Mikrotik!

Hi,
I was also having this issue, been testing a whole bunch of VPN configurations with Mikrotik and RADIUS.
As we know here the issue is not RADIUS, and is an intermediary certificate not being presented to windows by Mikrotik (Natively), it can be specified in the CLI and winbox.

The reason for my post, is that Its rather odd that in one VPN type setup (SSTP) you dont need to do the intermediate part (just specify the end certificate), but in another VPN type (IKEv2) you do need to set the end certificate and the intermediate certificate(s).
would be nice to have a standard here. But glad I found this topic, so very glad that I do not need to import certificates at the client end, makes the deployment that much easier.

thanks All.

does this works with Userman6?
i mean eap radius