As Paul says, Groovy sits on top of Java...but...over the years, I have noticed 
that people are often unaware of the flexibility in the JVM.
I have seen "how to make a certificate for Application X" documents that are 
several dozen pages long, filled with generations of accumulated "good stuff" 
but...a 3-line command sequence would actually suffice...

So: Just FYI,

These two links GREATLY help with debugging cert-related issues:
https://stackoverflow.com/questions/23659564/limiting-java-ssl-debug-logging
https://colinpaice.blog/2020/04/05/using-java-djavax-net-debug-to-examine-data-flows-including-tls/

I also find the following useful; just add it to a class that is early in your 
application's startup sequence:

// the following will help debug the HttpURLConnection, including showing all 
headers...
 static {
     ConsoleHandler handler = new ConsoleHandler();
     handler.setLevel(Level.ALL);
     java.util.logging.Logger jlog = 
java.util.logging.Logger.getLogger("sun.net.www.protocol.http.HttpURLConnection");
     jlog.addHandler(handler);
     jlog.setLevel(Level.ALL);
 }

*I* am of the opinion that "Thou Shalt Never Modify The JVM Installation" and 
this especially applies to the cacerts file. *I* always pass configuration 
options around, eg:

-Djavax.net.ssl.trustStore="..."
-Djavax.net.ssl.trustStorePassword=password
-Djavax.net.ssl.trustStoreType=PKCS12

(...many other properties exist, including keystore-related ones) Note that 
these properties are looked for 'automatically.' You should be able to specify 
them for your CI step.

One benefit of this is (especially in a closed infrastructure environment): 
YOUR stores can contain ONLY immediately relevant certificates...the cacerts 
file is a BIiiig catch-all blob. This is a nasty beast!

MUCH more at: 
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html

If you worry about sensitive info being leaked on the command line, you MAY be 
able to build a 'starter' class that simply asserts these into the 
System.properties Map and then starts your app proper, something like:

System.properties.with { p ->
    p['sun.security.ssl.allowUnsafeRenegotiation'] = 'true'
    p['javax.net.debug'] = 'ssl:handshake'

    p['com.unboundid.ldap.sdk.debug.enabled'] = 'true'
    p['com.unboundid.ldap.sdk.debug.level'] = 'ALL'
    p['com.unboundid.ldap.sdk.debug.type'] = 'LDAP,LDIF'

    p['javax.net.ssl.trustStore']='...'
 }

I'd also point you to: https://keystore-explorer.org/ a VERY nice tool for 
those who don't worship the command-line.

HTH,

BOB

-----Original Message-----
From: Paul King <pa...@asert.com.au> 
Sent: Friday, February 16, 2024 12:07 PM
To: users@groovy.apache.org
Subject: Re: How to add a ssl server cert for groovy?

Hi David,

Groovy sits on top of the JDK, so if you install cacerts into the JDK you are 
using, then Groovy should use them just fine.

Possibly there could be issues depending on what client library you are using 
to make the https connection.

Cheers, Paul.

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Fri, Feb 16, 2024 at 9:25 AM David Karr <davidmichaelk...@gmail.com> wrote:
>
> I work behind a firewall, and it requires that I add a cert for our proxy to 
> the cacerts file in the Java distribution. This works fine.
>
> I have a quite old version of Groovy installed on my desktop, v2.4.21, which 
> is the version used by our Jenkins pipeline script.  I want to test some code 
> in groovyConsole before I try to run it on our CI server. For many things, 
> this works fine. However, I'm trying to iterate on some code that makes a 
> https connection, and I'm getting an error in groovyConsole that I believe is 
> the same error I get when the server cert is missing ("PKIX path building 
> failed"), which isn't surprising because I never installed the root cert in 
> the Groovy distribution.
>
> I've never really looked inside the Groovy distribution before. I don't even 
> see a cacerts file or anything that really looks like it, so it must do this 
> in a different way than the Java distribution. Is it possible that this is 
> because I'm using such an old version of Groovy?

Reply via email to