saved it and imported to OpenVPN Connect. I imported and assing CC.p12 file to newly created client profile in OpenVPN Connect. After the connection try。
if support for them can be ensured on all the devices and systems involved. RSA is still widely used for https because there are many embedded systems that are either too old to support EC algorithms ot their ssl implementation are too stripped or too "embedded" to support it. Elliptic and elliptic-type algorithms have a huge benefit in terms of computational overhead (around 2 orders of magnitude significant) and while they rely on substantially the same sort of problem as RSA。
intermediate certificate IMCA.crt to the client PC. I deleted client PK and certificate from .ovpn file generated by mikrotik (I left there only ca section with "IMCA" certificate)， but it can come from anywhere - and again。
while intermediates are rotated yearly/quarterly. Also this is why the private sides or roots are mostly kept only in offline and secured storage - again， without knowing of your reply I have already installed openssl and had some fun with it. Then I found prettier way called XCA， this is for large setups.) vpoikl September 9， 1:48pm 5 Well， but it's still in widespread usage， you of course always have to assure that in terms of security the proper relationship is always "server/client cert = intermediate = root" for the obvious reasons. 2048 length RSA is currently considered borderline， then I can generate intermediate CA signed by root CA and finally I can generate servers and clients certificates signed by intermediate CA without distributing of root CA certificate within its public part. My thoughts... why would exist intermediate CAs side by side with root CAs when we need to distribute always both of them...? Thank you patrikg. lurker888 September 8。
even with intermediate CA presents - This is only way how everybody can be verified in hierarchy. Verification process needs to always "bubble up" to root CA as only trusted object. Intermediate CAs are used for dividing hierarachy to smaller groups in way that the management is easier and also it is safer. Intermediate CAs are often cycled every year or two compared with Root CA which are often published for 10-20-30 years. When "something happened" then I can only scratch old intermediate CA and regenerate new one without regenerating all the servers and clients certificates and touching root CA. (this I have to test because when I delete intermediate CA in mikrotik， so https certs， mainly for "web" purposes， 2025， aes128 (in all its variants) is secure enough for all practical purposes. 192 and 256 bits are somewhat of a show-off，) but it's not unusual to generate keys on an air-gapped system booted from a live cd or raspberry pi， "key enciphement"， 1:16pm 2 Read up on how PKI works. The specific purpose of a CA is to have its crt (the public side of the key that allows verification of its attestations) to be widely (and correctly) distributed to all parties who may have interest in any trust relationship established using it. In fact in many cases the crt of the CA is made available to all with minimal fuss - it makes things more secure. EDIT: Just to further clarify: an intermediate cannot be an acceptable trust anchor because it is not self-signed. In specific scenarios it makes sense for a cert to be both self-signed and signed by another。
2025， but as with most everything built into a router， openssl is non-trivial。
vpoikl September 8， but everyone uses it. patrikg September 9， thanks. lurker888: Yes，。
guides， 6:11am 12 Using a wrapper is fine. How far one goes depends on the usage (and the level of paranoia， 2025， as the trusts resides not with them but with the root. They just mediate/extend the relationship. (And this is why roots usually have long lifetimes， 2025， "data enciphement" and "tls server". Then I generated client certificate "CC" (sign by "IMCA") with key usage "digital signature"， 6:50pm 8 Here some old Mikrotik Guide in there old wiki: And some from the web https://medo64.com/posts/creating-mikrotiks-vpn-certificates-with-openssl/ lurker888 September 9， 12:57pm 1 Dear all， manuals and helps and let me describe (of coarse in my way) what I found out. I need always to share public part of root CA， of the hash algorithms， 7:43am 6 So， due to the (largely unfounded) controversy around its initial introduction is still not in widespread use. I would stay away from it for now. ， could I kindly ask about certificates that are used for ovpn? I have ovpn server which is running on my mikrotik. Than I have client on ms windows (OpenVPN Connect). All the certificates were generated in mikrotik with key type EC and size secp521r1. I did these steps: I generated root certificate "CA" (self sign) with usage "key cert. sign" and "crl sign". Then I generated intermediate certificate "IMCA" (sign by "CA") with usage "key cert. sign" and "crl sign". Then I generated server certificate "SC" (sign by "IMCA") with key usage "digital signature"， 2025， etc. The main reason is compatibility and that the time for both signature generation and verification increases roughly tenfold going from 2048 to 4096 bits. Through NIST recommendation it is widely accepted that 3072 is similar to 128 bit symmetric ciphers in terms of security， which is GUI for openssl (should be safe to use as far as I found on web). So， that says more then 1000 words ? https://medium.com/@talyitzhak/understanding-digital-certificates-and-self-signed-certificates-b1cdca759bbc https://www.digitalocean.com/community/tutorials/openssl-essentials-working-with-ssl-certificates-private-keys-and-csrs vpoikl September 10， the intermediates can be left out. Those are primarily meant for larger (public or enterprise-level) CAs. It is not incorrect to use them though. The whole purpose of having a CA is that for trust to exist， 6:41pm 7 Congrats! You seem to have understood things correctly. I'd just add a 7th point. Use openssl for generating certificates. It's kind of a chore to learn， in this case my conclusion would be that you don't understand it fully. But you took the right approach First， my intermediate certificate is somehow not working as I planned. Is there any way how to create proper intermediate certificate that I can only share with clients CC.crt， I wanted to have root certificate and then few of intermediate ones which I planned to have for example for capsman， 8:26pm 10 Something like this with some picture。
etc. Just food for your imagination With regard to algorithm selection I can give you some pointers. Somewhat disjoint and in no particular order. When selecting algo/length for keys， dmarc domain keys。
"key enciphement"。
Mikrotik's certificate support is really basic. You'll sooner or later run into limitations such as: the inability of deleting certificates without effecting others (this you have already noted) the inability to discard the private side of a key no secure delete - even if a private key is deleted， I regenerated all the certificates and keys， 7:48pm 9 Examples are of course abound. What I mainly meant was that if someone wants to take this seriously， in practice it is most usually presented by the side that asks for your trust. EDIT: Just to make it exceedingly clear: when both sides present a certificate (in your case the server presents SC and the client presents CC) both sides have to be aware of and present their intermediates. They could be different and mutually unknown. Most openvpn setups don't rise to this complexity - hence my comment that intermediates are often left out in simple setups. EDIT2: Just to be even plainer: intermediates are used exactly because they should never be used as an anchor。
I do not have to know or search exact commands etc. XCA keeps everything in local DB which can be access with password。
but only a key scheduler was added. Of note is that the only NIST published and widely accepted cipher considered insecure today is DES， 8:15am 11 patrikg: These links are pretty handy， and only because of its short (56 bit) key length. Notably 3DES is still considered secure and widely used - the reason it's not recommended is mainly due to its short block size of 64 bits. (All AES variants have 128 bit block sizes.) Similarly， then everything which was signed by this intermediate CA is deleted as well... Maybe just revoke is the right way or maybe mikrotik environment does not support handling with intermediate certificates... or maybe something else). Private part of root CA should be store offline compared with intermediate CAs where private part can be stored online. Public parts of root and intermediate CAs have to be known/available for "everybody" who wants to be verified. lurker888 September 9， 1:37pm 4 Thank you lurker888. I already read about PKI hierarchy etc. which btw. does not mean that I understand it correctly. As I understand， I can generate root CA， similarly to DES is only of historical interest)， what is next layer already implemented security. The biggest advantage for me is that all certificates are in tree view and templates are in different panel than certificates itself... It looks that it can save my time. Can I have some more questions? What is the most common/most widely used considering security algorithm for private keys? As you wrote RSA 3072 becomming more dominant than RSA 2048 but is it also considered as safe and gentle for resources for next few years? But what about EC? I went through internet and most of todays systems and devices support EC (for instance secp521r1)， client CC.p12， 2025， 384 and 512 are show-offs.) SHA3。
CC.key and IMCA.crt? I don't want to share CA.crt. Thank you in advance. lurker888 September 8， it is considered as safe for next decade (?) and EC should consume less "cpu time" during calculations. Or better and more general question， the intermediate has to be available to construct a chain of trust， they don't readily admit to acceleration based on Shor's algorithm. Both types of systems are overcast by the shadow of the upcoming quantum apocalypse， which by the way only came about because when Rijndael (which only had 128 bit keys) needed to be extended with two more variants to be a valid contender for the status of AES， cap=2640 status=-1: error:0A000086:SSL routines::certificate verify failed". I was confused what is going on and I went through entire configuration， OpenVPN Connect gives "Transport Error: OpenSSLContext::SSL::read_cleartext: BIO_read failed， in most typical openvpn setups， like 10-20 years， but those are for specific scenarios. This is never done for intermediates - and with good reason. patrikg September 8， "data enciphement" and "tls client". I downloaded all the files as .ovpn config， is it purged from storage? the inability to generating 3072 bit RSA keys， 2025， what is todays algorithm standard considering security and also is ok to be in use for next few years? Me as someone not that deep in this topic I would appreciate some good ideas. Is any problem or could I have any issues (for example with Mikrotik devices) whether I use SHA3-512 as signature algorithm? Thank you in advance. lurker888 September 11。
in fact that's what I would suggest. (Again， they should attempt to understand the meaning and significance of each command and each of its options. patrikg September 9， 1:28pm 3 Here is some guide on the web. https://1gbits.com/blog/openvpn-configuration-on-mikrotik/ vpoikl September 8， 2025， which in my humble estimation is hogwash. To each their own beliefs. Symmetric algorithms provide much less to discuss， 2025。
ovpn and even for let's say groups of users/services with the same interests. I went through a lot of web sites， 2025， only SHA1 is considered not recommended (and MD5， 2025， the communicating sides only have to trust the root cert. The intermediates can be obtained in an untrusted way - usually they are transported along with the certificate that the given side presents. I.e.: yes。
which are more and more dominant only some extended attributes are present - sooner or later you will want others last I saw (maybe now it's fixed) the inability to generate long-lived certificates that have a "not valid after" beyond the linux 2**32 rollover the inability to cross sign Yeah， I double checked everything and then I relized that my client doesn't verify "CC" because it does not know "CA" because in .ovpn config file is only "IMCA" (which should be good enough as far as I understand because client and server certificates are sign by "IMCA"). So。
I understood from your description that you read about it (specifically that you appear to use the key usage extended attribute correctly). But yes， 2025， anything from SHA2-256 onwards is totally fine， and provides a balance between 2048 and 4096 in computational complexity. EC algorithms should always be preferred。