Hi all,

I have successfully configured routeros to allow VPN clients to connect via IKEv2, backed with radius, and authenticating using EAP-TLS (no passwords). The config is below.

What I discovered is that this configuration would only work if I took the private key and certificate of our radius server and installed that certificate on the routerboard (certificate=certificate-of-the-radius-server.pem).

Obviously this is not great - I would prefer the radius server to have the certificate, not have this duplicated on the routers, which aren't necessarily as physically secure as the radius box is. Can anyone confirm why this is the case? What are the requirements on the certificate on the routerboard, why is the certificate in radius not good enough?
Regards,
Graham
--

Hi Graham,

What is 192.168.x.x and 192.168.y.y?

Regards
Isa

Hi all,

I have successfully configured routeros to allow VPN clients to connect via IKEv2, backed with radius, and authenticating using EAP-TLS (no passwords). The config is below.

What I discovered is that this configuration would only work if I took the private key and certificate of our radius server and installed that certificate on the routerboard (certificate=certificate-of-the-radius-server.pem).

Obviously this is not great - I would prefer the radius server to have the certificate, not have this duplicated on the routers, which aren't necessarily as physically secure as the radius box is. Can anyone confirm why this is the case? What are the requirements on the certificate on the routerboard, why is the certificate in radius not good enough?

Based on my limited experience with certs and CAs, I'm guessing the MT needs a cert and key for encrypted communication with the RADIUS server. Perhaps you need to create a cert for the MT and have the CA sign it so it is trusted.

Wait. Depending on how the certificate of the RADIUS is generated (self-signed or signed by CA), the RADIUS server must provide the complete chain and the Mikrotik must either have that certificate itself (if it is self-signed) or the CA certificate (if it is signed by a CA) in its trusted certificate store. In no case you should need a private key of the RADIUS server on the Mikrotik side. The certificate normally holds the public key which is used to encrypt the data, but the decryption is done using the private key which is not send anywhere. And you should not need any key separately, it comes inside the certificate.

Can you show the output of /certificate print? Change some bytes in the certificates' hex strings and the IP addresses, they are not important.

Wait. Depending on how the certificate of the RADIUS is generated (self-signed or signed by CA), the RADIUS server must provide the complete chain and the Mikrotik must either have that certificate itself (if it is self-signed) or the CA certificate (if it is signed by a CA) in its trusted certificate store. In no case you should need a private key of the RADIUS server on the Mikrotik side. The certificate normally holds the public key which is used to encrypt the data, but the decryption is done using the private key which is not send anywhere. And you should not need any key separately, it comes inside the certificate.

Can you show the output of /certificate print? Change some bytes in the certificates' hex strings and the IP addresses, they are not important.

Getting back to this.

In my case the certificate signed by a CA.

Flags: K - private-key, D - dsa, L - crl, C - smart-card-key, A - authority, I - issued, R - revoked, E - expired, T - trusted
# NAME COMMON-NAME SUBJECT-ALT-NAME FINGERPRINT
2 K L T x... x DNS:x x...
3 L T x... DigiCert SHA2 Extended ... x...
4 T x... DigiCert High Assurance... x...

- With certificate, full chain and key, radius works.
- With certificate and full chain but no key, radius does not work (no contact is made with radius)
- With CA certificate only, radius does not work (no contact is made with radius)

Looking into RFC 3579, I conclude that everything is correct - it is the Mikrotik, acting as a NAS in the RFC 3579's naming convention, which is authenticating its own communication with the clients using its own certificate signed by a CA which the clients trust, which implies that its private key must be available (as the manual properly reminds). The communication between the Mikrotik and the RADIUS server is only authenticated and partially encrypted using the shared secret, i. e. the RADIUS server doesn't use any certificate to authenticate itself, neither to the NAS nor to the clients.

The declared identity of the client is determined by the NAS (Mikrotik) from the client's certificate signed by a CA which the NAS trusts and provided to the RADIUS; the RADIUS then sends a challenge to the client via the secure channel established between the NAS and the client and expects a correct response to the challenge.

The holy Mikrotik Manual confuses people who aren't deep into the topic, stating that the certificate parameter of the peer is "applicable if RSA signature authentication method (auth-method=rsa-signature) is used", whereas for the eap-radius value of the auth-method parameter, it states that "Server certificate in this case is required". The only actual issue here is that only a single authentication method (rsa-signature) is mentioned in the explanation regarding the certificate parameter, whereas in reality it applies also to rsa-signature-hybrid and eap-radius methods.

I apologize for resurrecting an old thread by I am having the exact same issue as OP was years ago. The difference is that I am on RouterOS 7.10 and I have CA+Cert+Key of the RADIUS server already installed.. yet it does not work. No contact is made with radius when using IPSec RSA. It however works fine when using IPSec MSCHAPv2.

The certificate used in RADIUS is generated by Mikrotik, signed by a CA that was also generated by the Mikrotik. Therefore it has CA + Cert + Key for both the certificate used in RADIUS and the certificate in /ipsec identity.

Minfrin, are you still around? Have you migrated this setup to ROS7?