Community discussions

MikroTik App
 
tangent
Forum Guru
Forum Guru
Topic Author
Posts: 1351
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Using one MT box to sign TLS certs for another

Thu Jul 08, 2021 2:24 am

I've got HTTPS access properly set up on my CRS328 using a self-signed CA root, which I've imported into my OS's trusted root cert store. This means it trusts the regular TLS server cert I subsequently signed using it, so most HTTPS clients are happy to accept it.

I next wanted to set up my hEX S the same way, but rather than follow the exact same instructions, I says to myself, "Hey self, I know, I'll use the CRS328 as my CA for the whole site!" I'm clever that way, which causes no end of trouble. 🙄

I created a certificate for the hEX on the CRS328, signed it, exported it, and uploaded it to the other router. It imports and looks fine in System → Certificates on both sides, but after applying it to the www-ssl service, I can't get any HTTPS client to connect to it, including ones that successfully connect to the CRS328.

Firefox gives a SSL_ERROR_NO_CYPHER_OVERLAP error, meaning the browser and router couldn't agree on a common cipher suite. Chrome gives its version of the same complaint, ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

I therefore decided to dig deeper, asking the OpenSSL s_client tool (v1.1.1k) what it thinks:

$ openssl s_client -connect 1.2.3.4:443 -tls1_2 -CAfile /path/to/my/root/ca.crt
CONNECTED(00000003)
4406840768:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1544:SSL alert number 40
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 194 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1625699461
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---

I believe the problem is that "Cipher is (NONE)" bit: the router is returning no cipher list, and modern HTTPS clients will refuse to negotiate a null ciphersiute.

Both routers have the service configured as:

/ip service set www-ssl certificate=certname disabled=no tls-version=only-1.2

Does it matter that my CRS328 is running 7.1beta6 and my hEX S 6.48.3? I need the last stable version on the hEX for $REASONS, but I also want to play with the latest fun stuff, so that's how I've arranged it. Is the issue perhaps a lack of TLS 1.2+ in the ROS 6.x line?

I haven't tried minting a CA root cert on the hEX, since I don't see that the certificate controls what ciphersuites the HTTPS server offers. I've configured TLS before on other systems, and the two are separate areas of configuration.

I've tried both the CLI way and the WinBox way for creating and signing these certificates. I get the same symptoms either way.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11434
Joined: Thu Mar 03, 2016 10:23 pm

Re: Using one MT box to sign TLS certs for another

Thu Jul 08, 2021 8:24 am

Disclaimer: never tried myself.

Did you import the private key that goes with certificate as well? This thread contains some hints on what needs to be done ...
 
tangent
Forum Guru
Forum Guru
Topic Author
Posts: 1351
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: Using one MT box to sign TLS certs for another

Thu Jul 08, 2021 7:41 pm

It's an interesting idea, using certificate signing requests (CSR) instead of generating the initial certificate directly on the CA router, but it doesn't help.

That RouterOS software feature is meant for use with external CAs, where you don't have the direct generation option, as when getting a globally-trusted certificate from one of a public root CAs. When the CA is under your direct control, CSRs just add a pointless layer of indirection.

For me, an external CA isn't even an option since my MTs aren't publicly-visible, with the public DNS names needed to support that. For the same reason, I can't use the 7.1 beta's Let's Encrypt feature, either. I know how to run Let's Encrypt, so it's not a knowledge problem. I just don't want my MTs exposed publicly, so I have to arrange for self-signed certificates. Thus this thread.

Worried that I was conflating two problems — getting the certificate signed and getting the ROS 6.48.3 box to negotiate an HTTPS connection — I created a CA cert on the second router and used it to create a self-signed TLS cert, and it worked!

Therefore, there seems to be a bug in this cross-router certificate generation case. Neither the direct path nor the CSR path works. Simple test case, starting on R1, acting as the local CA root:

[admin@r1] > /certificate add name=CA common-name=r1 subject-alt-name=IP:10.0.1.1 trusted=yes key-usage=key-cert-sign,crl-sign
[admin@r1] > certificate add name=R2-TLS common-name=r2 subject-alt-name=IP:10.0.2.1 trusted=yes key-usage=ipsec-tunnel,ipsec-end-system,tls-server
[admin@r1] > /certificate sign ca=CA R2-TLS

I put the IPsec stuff in the "key-usage" value for the R2-TLS cert because I'm trying to avoid re-minting the key for additional services I plan to set up later. Adjust to taste. I doubt it has any effect on what I'm showing here, as long as "tls-server" is included.

I've also added values for country, state, locality, organization, and unit to the "add" commands, which aren't important to publish here.

With this direct path, you then export the R2-TLS cert to Files, download it, upload it to R2, import it there, and then set www-ssl to use it. If I'm right that there's a bug here, you should then see the errors I reported up-thread when trying to visit https://r2/ while https://r1/ works fine.

The parent post recommends a variation with only the first command above given to set up the CA root. You give the second command above on R2 now, creating what RouterOS calls a "template," but which everyone else just calls an unsigned certificate. You then use the CLI or the GUI to create a CSR from it, export that to a file, download it to the local computer, and upload it to R1. At that point, you say the following on R1 instead of giving the simpler "cert sign" command above:

[admin@r1] > /cert sign-certificate-request ca=CA file-name=certificate-request.pem

After that, it's the same process: export, download, upload, import, and attach it to the service. Same result: HTTPS to R1 works while HTTPS to R2 does not.

Why in the world would the certificate affect which TLS cipersuites the www-ssl service is willing to offer?
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11982
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Using one MT box to sign TLS certs for another

Thu Jul 08, 2021 7:56 pm

For web service must have (at least, if not CA) digital-signature,tls-client,tls-server and also the "K" for private key installed...
 
tangent
Forum Guru
Forum Guru
Topic Author
Posts: 1351
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: Using one MT box to sign TLS certs for another

Thu Jul 08, 2021 8:14 pm

If that were true, why do my successful keys not have those flags set?

The digital signature flag is needed when signing documents. That doesn't happen in TLS, which is why tls-server is a separate flag.

The TLS client flag is meant for client authentication, which almost no HTTPS server requires. (To a rough approximation, it's like RouterOS's 802.1x feature, where the client proves that it's allowed to connect.) If RouterOS used this key for that purpose, it would only apply to the RouterOS making outbound TLS connections.
 
tangent
Forum Guru
Forum Guru
Topic Author
Posts: 1351
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: Using one MT box to sign TLS certs for another

Thu Jul 08, 2021 8:57 pm

...and also the "K" for private key...

That sparked a thought, and I think I now know what's happening: the RouterOS certificate Export function is exporting only the public half of the key!

I can see that that's what you want some of the time, but in this case, www-ssl on the other router needs both halves. It doesn't matter if you go via a CSR or directly on-device, exporting the key gives the web server only half of what it needs to do TLS encryption.

I can't see any way to force RouterOS to give me both halves.

I suspect this is a shortsighted security measure, for the same reason that it doesn't dump certificate info in /export output.

Until MikroTik decides to fix this, there are two weak alternatives: run your own CA somehow, such as via raw "openssl" commands, or do per-router CA setups.
 
tangent
Forum Guru
Forum Guru
Topic Author
Posts: 1351
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: Using one MT box to sign TLS certs for another

Thu Jul 08, 2021 9:27 pm

Incidentally, there's a secondary use case for being able to download both halves of the certificate: backups via /export contain no certificate info, so if you reset a router to factory settings and then try to restore via CLI commands, you may end up with a router you can't log into because you've got the HTTP-only web server turned off and no certificates to back the HTTPS one.

I realize there's a "binary" backup file format, but that one doesn't always restore properly. There should be a method to restore a router to the prior settings with only CLI commands. At least that way, if there's an incompatibility between the machine that took the backup and the one restoring it, you can hand-edit the file to avoid the problematic bit.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11982
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Using one MT box to sign TLS certs for another

Fri Jul 09, 2021 2:51 am

It's clear: You do not know how the export certificate work.
Stop making supposition and writing bullshits.
If you do not know how RouterOS works, you can only write thousand of nonsense.

If you do not export WITH PASSWORD you do not export the private key.
Instead to do random complain, study how RouterOS works.

From the post... #2!!!
Did you import the private key that goes with certificate as well?

Based on this (full export of every aspect):
viewtopic.php?f=1&t=175360&p=858564#p858564

:local certpass "myprivatepass"

/certificate
:foreach cert in=[find] do={
 :local certname [get $cert name]
 export-certificate $cert file-name=("auto_$certname") type=pkcs12 export-passphrase=$certpass
}
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11982
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Using one MT box to sign TLS certs for another

Fri Jul 09, 2021 3:11 am

backups via /export contain no certificate info, so if you reset a router to factory settings and then try to restore via CLI commands,
you may end up with a router you can't log into because you've got the HTTP-only web server turned off and no certificates to back the HTTPS one.

Try to specify only one real VALID motive to turn off MAC telnet, MAC winbox, winbox, ssh, telnet, http (except API, I miss someting???) and leave enabled only https.
 
tangent
Forum Guru
Forum Guru
Topic Author
Posts: 1351
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: Using one MT box to sign TLS certs for another

Fri Jul 09, 2021 4:26 am

It's clear: You do not know how the export certificate work.

Here's the official documentation for certificate exporting: Source. Where on that page does it say it will export only the public key if you don't give a passphrase?

I didn't give one because I'm downloading this on a private LAN to a private computer, and I'm storing the resulting files in an encrypted vault. In absence of documentation telling me otherwise, I saw no reason to apply a passphrase to the key files.

Stop making supposition and writing bullshits.

How do you expect to advance the cause of MikroTik by being rude to newbies? If you teach me, you get a helper on this forum. Are you trying to run me off?

I was right about the key-usage field, by the way: my new keys have only tls-server set, and they're working just fine. I've decided to mint separate IPsec certs later.

If you do not know how RouterOS works, you can only write thousand of nonsense.

So we're required to learn RouterOS inside and out before posting? I thought the point of this place was to get help and learn things.

From the post... #2!!!

...which also doesn't say that giving a passphrase is necessary to make this work. Both this and the official docs gave me the impression that this was an optional step. If your point is that I need to slavishly imitate every command I see, I wonder what sort of audience you think you have here? The whole point of RouterOS, to my mind, is that it gives you tremendous freedom to create custom solutions. That means users are expected to change examples to suit their perceived needs.

I admit, I screwed up here, but instead of teaching, you're yelling and belittling. I get that you're some kind of big wheel here, but that isn't a productive tactic.

Try to specify only one real VALID motive to turn off MAC telnet, MAC winbox, winbox, ssh, telnet, http (except API, I miss someting???) and leave enabled only https.

That's a straw man. I never said I was going to turn off everything but HTTPS. I wrote only of disabling HTTP.

As to the "why" of it, I turn off all unencrypted services as soon as I'm able to. The reasons and best practices here are well known. For the same basic reasons, I've already disabled unencrypted API access, Telnet, and FTP, since I have SSH and HTTPS to take care of all of that. I have yet to figure out how to do encrypted WinBox, but I'll get to that soon.

Now that I have both halves of my TLS keys downloaded and backed up safely, I can restore my MikroTik routers from a plain-text backup more easily, re-enabling encryption as soon as possible.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11982
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Using one MT box to sign TLS certs for another

Fri Jul 09, 2021 9:50 am

This is user forum, I do not act on behalf of MikroTik, do not suppose again than MikroTik do etc. etc. etc.

I don't want to answer all of your other points, because they are off this topic.

...which also doesn't say that giving a passphrase is necessary to make this work.
You do not reply on his question.
Did you import the private key that goes with certificate as well?
If you do that first instead of supposing something...
If there is no collaboration, right from the start, how do you expect someone to help you correctly?
Remember that they are people who devote their time to helping others without any gain.

The only example on help you link is
/certificate
export-certificate CA-Template
export-certificate ServerCA export-passphrase=yourpassphrase
export-certificate Client export-passphrase=yourpassphrase
export-passphrase=yourpassphrase is present.
then that the guide is badly done, there is no doubt from my point of view
Migration from wiki to help is on progress, but wiki is still more complete, but not complete...
https://wiki.mikrotik.com/wiki/Manual:C ... rtificates


...I never said I was going to turn off everything but HTTPS. I wrote only of disabling HTTP...
you have wroted that:
>>> so if you reset a router to factory settings and then try to restore via CLI commands,
>>>you may end up with a router you can't log into because you've got the HTTP-only web server turned off and no certificates to back the HTTPS one
wroted on this way "you can't log into" appear to be all other ways to login disabled, not???


If you wanted or not, now you know another piece of this mosaic.
And if you still need something, you find all the users help, also mine.
 
biomesh
Long time Member
Long time Member
Posts: 561
Joined: Fri Feb 10, 2012 8:25 pm

Re: Using one MT box to sign TLS certs for another

Fri Jul 09, 2021 2:18 pm

Certs when exported without a password are almost always just the pubic key - this is true for pretty much any application available. While you can export clear keys, it is not recommended.

Choose pkcs12 as the export format and set a password/passphrase when exporting.

From what I see, if you choose pem format you will get a crt and key file respectively. Using a pkcs12 file with password is so much easier.

Who is online

Users browsing this forum: bananaboy1101, dido1236, jamesperks, Michiganbroadband, tinodj, xristostsilis and 78 guests