Say I have the following certification chain
some_company
|______ some_company_technical
|_____________some_cert1
some_cert1 will be replaced every year. By importing the Root certificate and the Intermediate certificate into my client's truststore...
keytool -import -trustcacerts -alias some_company -file some_company.crt -keystore some_client.jks
keytool -import -trustcacerts -alias some_company_technical -file some_company_technical.crt -keystore some_client.jks
...will some_cert1 (and some_cert2, some_cert3 .... some_certn signed the same way) be recognized as a trusted certificates by my application or am I misunderstanding how truststore works ?
As long as the some_certx is signed by the same SubCA/CA, and if these CA certificates are trusted by the client, you should be good, meaning the some_certx will be recognized as trust certificate.
How and Why?
Clients (eg: browser) that communicate with secured servers see if the server's certificate is signed by a CA that the client trusts. If the server's certificate is signed by a CA that client doesn't know about, there is no chain of trust. In simple words, the client doesn't trust the organization (CA) that trusted the server. This is what chain of trust means, do I trust the organization that trusted you? If I trust the organization that trusted you, I can trust you.
You might be thinking what the role of the end-entity (some_certx) would be. The clients have their ways to check the validity and status (revoked or not) of the certificate. The data required for these checks can be found in the end-entity certificate itself. The validity of the certificate can be verified using the Valid from and Valid to fields, and the status of the certificate can be checked using CRL or OCSP. The URLs for these can be found in CRL Distribution Point or Authority Info Access extensions of the certificate.
If either of the 2 above conditions fail, the server cannot be trusted.