Guestbook

[Hakky54]

Hi all 👋🏼

First of all I appreciate that you guys are using this library! I am very happy to see the community is growing.
I hope it is making your life easier when configuring ssl for your server of http client. This library is grown to the current state thanks to the ideas and feedback from the community.

I am curious about your use case and would love to hear your story.

• How did you find this library?
• What challange/problem did it solve for you?
• Is it easy to use?
• What can be improved?
• Which functionality are you using?
• Would you like to showcase your code snippets of your use case?

[singhmann1]

Hi,

Just had a quick question, does this library support calling withTrustMaterial for PEM files as well as JKS. I wish to enable the SSLFactory also by using some certs I have in .PEM files instead of importing into my JKS which is already working with the library

Thanks

[Hakky54]

Yes, that is possible. There is an extension library available which provides all of the options to load pem files from classpath/filesystem/inputstream. See here for detailed documentation: https://github.com/Hakky54/sslcontext-kickstart#using-pem-files. An example code snippet while using pem files would be:

X509ExtendedKeyManager keyManager = PemUtils.loadIdentityMaterial("certificate.pem", "private-key.pem");
X509ExtendedTrustManager trustManager = PemUtils.loadTrustMaterial("some-trusted-certificate.pem");

SSLFactory sslFactory = SSLFactory.builder()
    .withIdentityMaterial(keyManager)
    .withTrustMaterial(trustManager)
    .build();

[singhmann1]

withTrustMaterial(is, truststore ...) is working
also want to invoke withTrustMaterials(is, PEM..)

[Hakky54]

I have posted the answer here: #302 (reply in thread) It is possible however slightly different. You need to use the PemUtils and provide the returned object to the SSLFactory

[singhmann1]

Hi,

I have added the certificate which is a Self-signed cert in a PEM file and initialised with .withTrustMaterial(/path/cert.pem)

In connecting to the server with a self signed cert I am getting SSL error None of the trustmanagers trust this certificate.

I have enabled SSL debug and can see the self signed certificate in the logs.

Is there any other change I need to make?

Thanks

[Hakky54]

It seems like the certificate file which you have added is not the same as what the server is providing and therefor also complaining that none of the trustmanagers are trusting the server certificate. Can you extract the server certificate with Certificate Ripper in pem format and retry?

[rogergcc]

I haven't used this library yet and I found it searching a image o icon about android + key in google images
and first option was the thumbnail of this repo

In other hand im interested i sslpinning or certificate pinning usin Publick Key(PK) technique for Android kotlin
a something related to no allow self-signef certificate for in a app

[Hakky54]

Hi mate, thank you for sharing your journey! I am not an Android Developer, however I know that SSL pinning is a common practice however, I found out that it is obsolete. If you are still seeking for a way to configure SSL pinning, this might be useful while using okhttp https://stackoverflow.com/a/33935744/6777695

If the self signed certificate is not added to the truststore it won't be trusted, so that one should be easy to not allowing self signed certificates

[nhysteric]

Hi there,

I'm working on a Spring Boot project that requires SSL reloading at runtime. Thanks to your excellent work on instant-server-ssl-reloading, it works perfectly in my project.

However, I've encountered another issue: I need to disable ssl.client-auth for specific endpoints. I tried using the traditional SecurityFilterChain approach, but it didn't work as expected.

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    @Order(Ordered.HIGHEST_PRECEDENCE)
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http.authorizeRequests(requests -> requests.antMatchers("/test/hello").permitAll());
        return http.build();
    }
}

Even the denyAll() configuration doesn't work. If I disable ssl.client-auth, the SecurityFilterChain works as expected. It seems that the mTLS configuration at the Jetty server level takes precedence before the request reaches Spring Security.

Is there any way to resolve this?

Thanks!

[Hakky54]

To be honest I never thought about this kind of use case, very interesting! Currently this is not possible with the library itself and the workaround with SecurityConfig within spring would not do the trick as it will happen at another level whereas the server requests the client certificate. I need to investigate this whether it is possible at all, I will ping you as soon as I make progress on this topic

[nhysteric]

Ok. Thank you for your reply. Looking forward to hearing your good news

[Hakky54]

Just wanted to give you some update from my side. It might be possible. I found a way to customize the request which the server will do for client authentication. I am currently investigating this with a Netty server. Spring uses Tomcat by default, I think it will be also possible with vanilla Spring server to be honest. I just need some additional context from you. In your earlier example you mentioned the endpoint of a server to permit so no client certificate authentication for a specific endpoint, is that correct? Or do you have other rules which you have in your mind?

I just need to do some additional investigation to provide you the full details to get it working.

[nhysteric]

Sorry, my email system has marked your reply as spam, which is why I am only seeing your reply now.😂
Yes, I hope MTLS can be disabled at certain endpoints. In fact, in my context, the client and server need to exchange certificates through these endpoints.
Additionally, I followed your tutorial and used Jetty as my Spring Boot server, but the tutorial on using Tomcat doesn't seem to work for me.🤔
Thank you again for your reply.

[Hakky54]

No worries. So what I found was that it is possible however, during the the sslhandshake it is not possible to know which endpoint is being called. It is possible to get some information from RequestContextHolder.currentRequestAttributes() however this is null during the ssl handshake process. So it does not make sense to add this client authentication customizer from the library perspective as it cannot get any information of which endpoint is called.

What I think would be better is to have multiple server connectors. Each server connector can have their own ssl configuration so 1 with client auth and 1 without client auth. Here is an example of adding servcer connectors: https://github.com/Hakky54/java-tutorials/blob/main/instant-server-ssl-reloading/server/src/main/java/nl/altindag/server/config/ServerConfig.java#L38-L40

It seems like in spring boot you can customize the server to have sort of a route. A specific servlet can be routed with a list of configurations, as shown here: https://www.baeldung.com/spring-boot-context-hierarchy The downside of this approach is that you will have 2 different ports within one application and I am not quite sure whether that will be an issue however, with nginx you can route that. So from the outside it cal look like it is the same port but it will be forwarded. Although I have 10+ years of experience in Spring, I dont have in dept knowledge and experience regarding this kind of specific configuration related to spring itself. I have tried it to get it working on my side with multiple server connectors and custom ssl configuration for both of them, but I could not get it working. Technically it is possible as Spring provides these options. I would recommend to consult with a spring expert to be honest.

[yingzhuo]

How did you find this library?

stackoverflow.com

What challange/problem did it solve for you?

I hate PKCS#12 and JKS, but i do not know why.

Is it easy to use?

Yes, It is. The document is very clear. even my English is so bad.

What can be improved?

Maybe a sub-project of spring-boot-starter ?

Which functionality are you using?

PemUtils and Apache5 Decorator

Would you like to showcase your code snippets of your use case?

// sorry. my hateful company own the copyright. I can show code here

[Hakky54]

Thank you for dropping a message here!

Maybe a sub-project of spring-boot-starter ?

This page might be usefull as it contains also server configuration alongside with this library, see here: https://github.com/Hakky54/java-tutorials

[paulhilliar]

This library is so easy to use - thank you for providing it. I came across it on StackOverflow and am using it to create SSLSocketFactory instances where the trust store is certificates in a pem file.

    @Builder
    public record SslBuildingBlocks(
        @NonNull SSLFactory sslFactory,
        @NonNull X509ExtendedTrustManager trustManager) {}

    private void loadCaBundle() throws IOException {
        log.info("Loading CA bundle");
        byte[] content = Files.readAllBytes(bundlePath);
        try (ByteArrayInputStream trustedCertificates = new ByteArrayInputStream(content)) {
            X509ExtendedTrustManager trustManager = PemUtils.loadTrustMaterial(trustedCertificates);

            this.sslBuildingBlocks.set(SslBuildingBlocks.builder()
                    .sslFactory(SSLFactory.builder().withTrustMaterial(trustManager).build())
                    .trustManager(trustManager)
                .build());
        }

        caBundleContent =  content;
    }

Then the OK Http client is rebuilt whenever the CA bundle changes

    private static OkHttpClient buildClient(OkHttpClient initialClient, CaBundleManager caBundleManager) {
        val sslContext = caBundleManager.getSslBuildingBlocks();
        //see https://square.github.io/okhttp/5.x/okhttp/okhttp3/-ok-http-client/index.html
        //"You can customize a shared OkHttpClient instance with newBuilder. This builds a client that shares the same connection pool, thread pools, and configuration.
        // Use the builder methods to add configuration to the derived client for a specific purpose."
        return initialClient.newBuilder()
            .sslSocketFactory(sslContext.sslFactory().getSslSocketFactory(), sslContext.trustManager())
            .build();
    }

OkHttpClient requires an explicit trust store to go with the SSL Socket Factory.

In use so far it's been perfect - so easy to get going with and the examples are useful for a bunch of different scenarios

[Hakky54]

Nice example of using it alongside okhttp client! I didn know that a newBuilder could be called on an existing client instance to recreate it with a new ssl configuration. Thank you for sharing this