http://coldfusion.com logo
Join Slack
Powered by
I'm receiving an error when I `box install` for a ...
# box-products
s
I'm receiving an error when I 
box install
for a project that uses cbdebugger, which I believe was updated yesterday, according to Forgebox. The error is: 
Connection failure <https://repo1.maven.org/maven2/com/github/vertical-blank/sql-formatter/2.0.3/sql-formatter-2.0.3.jarPKIX> path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
My main application is pinned to cbdebugger ^2.0.0 but apparently another module in my app has cbdebugger@stable as a dependency and that's where it goes awry. I modified the module dependency to ^2.0.0 as a workaround and I can get the app installed now.
b
@seandaniels really has nothing to do with cbdebugger
The SSL libs in Lucee/java are refusing to connect to the maven server
Copy code
unable to find valid certification path
This means the host is configured to use an SSL cert which is not trusted
First question is what version of CommandBox you're on, which determines the version of Lucee.
If that's super old, you may have a really old trust store
The more likely scenario however is you are on a network doing some sort of sneaky SSL spying where your firewall swaps out the "real" SSL cert with a self-signed one so they can spy on all your secure traffic
You can usually tell if this is the case by running the following in CommandBox
Copy code
#sslcertificatelist  <http://repo1.maven.org|repo1.maven.org>
which will show you what SSL cert chain is being presented
When I run that, I get this
Copy code
[
    {
        "subject":"CN=<http://repo1.maven.org|repo1.maven.org>",
        "issuer":"CN=GlobalSign Atlas R3 DV TLS CA H2 2021, O=GlobalSign nv-sa, C=BE"
    },
    {
        "subject":"CN=GlobalSign Atlas R3 DV TLS CA H2 2021, O=GlobalSign nv-sa, C=BE",
        "issuer":"CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R3"
    }
]
s
This is an AWS server in a VPC so I kinda doubt it's the spying scenario? I'm checking the commandbox / lucee version on that server right now
Copy code
CommandBox> #sslcertificatelist  <http://repo1.maven.org|repo1.maven.org>
{
    "COLUMNS":[
        "subject",
        "issuer"
    ],
    "DATA":[
        [
            "CN=<http://repo1.maven.org|repo1.maven.org>",
            "CN=GlobalSign Atlas R3 DV TLS CA H2 2021, O=GlobalSign nv-sa, C=BE"
        ],
        [
            "CN=GlobalSign Atlas R3 DV TLS CA H2 2021, O=GlobalSign nv-sa, C=BE",
            "CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R3"
        ]
    ]
}
CommandBox version on that server farm is 5.2.0+00280 currently.
Actually one of the servers in the farm is slightly newer image with CommandBox 5.4.2 and returns
Copy code
CommandBox> #sslcertificatelist  <http://repo1.maven.org|repo1.maven.org>
[
    {
        "subject":"CN=<http://repo1.maven.org|repo1.maven.org>",
        "issuer":"CN=GlobalSign Atlas R3 DV TLS CA H2 2021, O=GlobalSign nv-sa, C=BE"
    },
    {
        "subject":"CN=GlobalSign Atlas R3 DV TLS CA H2 2021, O=GlobalSign nv-sa, C=BE",
        "issuer":"CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R3"
    }
]
But my deploy process fails if any of the servers in the farm fail, which at least one of them is with that error during 
box install
so...
I'll try bumping the rest of the servers up to the newer image and see if that resolves it.
b
The certs looks correct and that's not an ancient version of CommandBox/Lucee so that's good
Now, it doesn't help us find out what's happening, lol
Sometimes you can get a better error message if you try and hit the URL with http directly
Try running this from the CLI
Copy code
repl 'http url="<https://repo1.maven.org/maven2/com/github/vertical-blank/sql-formatter/2.0.3/sql-formatter-2.0.3.jar>"; echo(serializeJSON(cfhttp));'
Note, you've got to run that on the actual server that's getting the error in the network it's erroring on.
Also, if you can, you can test the same URL via 
curl
just for funsies (or in a browser)
However, curl and your browser will use your OS ca store, so they may work in some cases were Lucee/Java fail
@seandaniels Any progress on this?
s
Sorry, my workaround of pinning to cbdebugger@^2 solved the deployment issue and I've been to busy to investigate further. But I will go back to cbdebugger@stable and see if I can get this happening again. I'm pretty sure it's just the version of CommandBox I've got on a couple of the servers in the cluster is too old. I have three servers running 5.2 and one server from a newer image running 5.4. I'll do some testing when I get a chance and report back. Thanks for following up.
m
It's possible the root cause is with my sqlFormatter extension, which points to that Maven package as a dependency.
I can bundle that jar into the sqlFormatter module instead of asking CommandBox to download it from Maven. šŸ™‚
s
So, I tried installing cbdebugger@stable locally and I get the same error. This is with the latest stable version of CommandBox - v5.4.2+00453. It seems like cbdebugger module actually installs but yea, the sqlFormatter module dependency does not complete install, and my application will not start, I assume because of that (I get 
Cannot activate module: cbjavaloader. Already processed API,translators,sqlformatter,diff,plaid,textsimilarity,minfraud,paypal,geoIP,cbsecurity,jwtcfml,cloudinary,cbi18n,socketlabs,towerdata,mongoentity,cbauth,awscfml,recaptcha,geonames,HTMLHelper,ekata,cbstorages,mailboxlayer,schemaorg,algolia,cbcommons,cbdebugger,autodeploy,stripecfml,route-visualizer,threatmetrix,libphonenumber,tineye,sitemaputils,linkedin,safebrowsing,convertedplugins,JSONPrettyPrint,webpurify,dotenvsettings,exchangerates,telesign,contentful,numverify,cbvalidation
).
@bdw429s I ran your suggested repl from the CLI and get this:
Copy code
{
  "status_text": "Connection Failure",
  "charset": "",
  "text": true,
  "errordetail": "Unknown host: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target",
  "filecontent": "Connection Failure",
  "responseheader": {},
  "statuscode": "Connection Failure. Status code unavailable.",
  "header": "",
  "status_code": 0,
  "mimetype": "Unable to determine MIME type of file."
}
b
@seandaniels Ok, so pretty much the same info as before. Basically,l the trust store Lucee is using doesn't trust the root SSL cert in use by repo1.maven.org or one of its intermediate certs.
The version of Lucee that CommandBox 
5.2.0
used was 
5.3.7.47
https://github.com/Ortus-Solutions/commandbox/blob/v5.2.0/build/build.properties#L13
s
Right, but just to be clear I get the same with CommandBox 
5.4.2
b
2 years old
šŸ¤¦ 1
root certs are usually issues for a very long time
I'm not sure how recent the SSL cert is that repo1.maven.org is using
m
@bdw429s Weird, do you know why I am able to 
box install jar:LINK_TO_MAVEN
then?
s
Yup, understood. I'm just confused as to why I seem to be the only one experiencing this issue? Lots of folks use cbdebugger, no?
ā˜ļø 1
b
outch, the intermediate cert is from 2021
That's probably your issue right there
Lucee's cacerts is a couple years out of date and maven "recently" updated to a pretty new cert
now, I'm not entirely sure why it works fine on my machine šŸ¤”
Though I am using the Lucee snapshot builds
And Lucee did literally update their cacerts file this week
The last update before today was on June 25, 2021 and used whatever trust store shipped with java 11.0.11
s
So you are saying the version of CommandBox you are using uses a snapshot build of Lucee?
b
why I seem to be the only one experiencing this issue
Who knows. I stopped trying to answer questions like that years ago šŸ˜†
šŸ˜‚ 2
Lots of folks use cbdebugger, no?
Not really, IMO. It's also a matter of what version they're using.
the version of CommandBox you are using uses a snapshot build of Lucee?
Locally, on my PC, yes.
The CommandBox 5.5.0 alpha
From the JIRA traffic, (and messages from Zac), Lucee 5.3.9 looks to be shipping today
And when it does, CommandBox 5.5.0 will finally ship too
in the mean time , you could just try popping in the laset 5.3.9 jar to CommandBox, wipe the 
engine
folder and cross your fingers
That may at least rule out a couple things
Unfortunately, CommandBox is just an innocent bystander here. We're dependent on java, and to a greater extent, Lucee to have a current SSL trust store for HTTPS to work šŸ˜•
m
It's also a matter of what version they're using.
100%, yes. @seandaniels the sqlFormatter module is only used since cbdebugger 3.3.0. https://github.com/coldbox-modules/cbdebugger/releases
šŸ‘ 1
s
OK. I'll sit tight. @mborn if you wanted to bundle that jar directly in cbdebugger instead of calling out to Maven that would also probably remove the issue. Mean time I'll stick on cbdebugger@2
šŸ’„ 1
m
Working on it, @seandaniels. Having a bit of a mid-life crisis with GitHub Actions, so it's taken longer than expected to get the new sqlFormatter version out.
s
Heh, no worries.
b
@mborn I wouldn't put the jar in the github repo, but you could easily ā€¢ just include it in the S3 zip by having it downloaded as part of your build when you run 
forgebox pubish
ā€¢ put a mirror of the jar on Ortus' S3
šŸ‡ŗšŸ‡ø 1
In reality, it's only a temp fix since there are a number of things that pull jars from Maven so I would expect it to be biting more people eventually
šŸ‘ 1
šŸ¤” 1
m
Note that we'd have to bump cbdebugger versions too to pull the latest sqlFormatter module... unless I modified the current version of sqlFormatter. And I'd consider that a no-no.
b
not neccessarily
I assume cbdebugger uses a semver range, no?
It's probably pulling the latest minor/patch updates for formatter
m
Doh, you're right - it probably does.
b
If Eric were here, he'd probably grumble something about CommandBox not supporting a package lock file right about now šŸ˜†
m
Derp - 
"sqlformatter":"^1.0.1"
šŸ‘ 1
b
Even though we're about to totally exploit that!
2 Views
Open in Slack
PreviousNext
Powered by