DEV Community

Cover image for Golang x509 Cert Issue: TLS Workaround for Jenkins Connection
Manav Bhatia
Manav Bhatia

Posted on

Golang x509 Cert Issue: TLS Workaround for Jenkins Connection

In the ever-evolving landscape of software development, encountering unexpected challenges is par for the course. If you’ve found yourself grappling with a perplexing x509 cert issue while working on a Golang script with the golang-jenkins library, fear not — you’re not alone. This article aims to shed light on a specific x509 cert problem related to the “cannot verify signature: algorithm unimplemented on net/http” error and provide a workaround that involves handling TLS versions in Golang.

Understanding the x509 Cert Issue

The x509 cert issue you’re facing often arises due to compatibility issues with the TLS handshake process. In this case, it seems that TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 is currently broken in Go, and the only feasible workaround is to downgrade the TLS MaxVersion. This workaround is expected to be effective until the support for the problematic cipher suite is introduced in a later version of Golang.

Unraveling the Workaround

The golang-jenkins library, unfortunately, does not provide a straightforward way to specify the HTTP client it uses, as it relies on http.DefaultClient. However, there’s a clever workaround to tackle the TLS MaxVersion issue by overriding the http.DefaultClient.Transport.

In the initialization section of your Golang script (funcinit()), you can implement the following code snippet:

package main

import (
"crypto/tls"
"net/http"
)
funcinit() {
cfg := &tls.Config{
MaxVersion: tls.VersionTLS11, // You can try tls.VersionTLS10 if needed
PreferServerCipherSuites: true,
}
http.DefaultClient.Transport = &http.Transport{
TLSClientConfig: cfg,
}
}

This code effectively configures the TLS settings for http.DefaultClient, allowing you to control the MaxVersion and address the x509 cert issue.

Conclusion

Navigating through x509 cert problems in Golang can be challenging, but armed with the right knowledge and workarounds, you can overcome these hurdles. By understanding the nature of the TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 issue and implementing the suggested workaround in the golang-jenkins library, you can continue connecting to your internal HTTPS server with confidence.

Remember, software development is a collaborative journey, and solutions to common issues often come from sharing knowledge within the community. So, don’t hesitate to share your experiences and insights with others facing similar challenges.

Top comments (0)