http://coldfusion.com logo
Join Slack
Powered by
Who knows how to make sure a certificate is recogn...
# adobe
d
Who knows how to make sure a certificate is recognized by JRE when using cfhttp??? Details in thread.
application A in siteA.domain.com does an cfhttp call to siteB.domain.com and I get the following error:
So for many years I have solved this by adding the certificate to the JRE cacerts list/keystore.
our certs at Psomas use GlobalSign, which is a known certificate provider and JRE cacerts does contain globalsign certs in its list, but somehow our cert is not recognized.
g
I just encountered that same issue yesterday for an internal SOAP endpoint and decided to use CURL instead.
d
lol
not a bad solution.
lol
what does your code look like to use curl? how do you replace a one liner for cfhttp?
g
CURL & CFX_HTTP5 both have the ability to ignore SSL errors. It comes in handy sometimes, but CFHTTP can't ignore it. (I spoke with my .Net brother. He stated that the ability to ignore built into their platform.) We scrambled once because a 3rd party's certificate expired and they didn't notice it immediately. We were almost dead in the water until we enabled the flag w/CCC_HTTP5.
CURL? It depends on what you need to do. When it came to working with a MLS RETS API, I could never get CFHTTP to work and CURL worked the first time I tried. It has been in production ever since and has survived every CF upgrade & update.
d
cfhttp failing - that sucks
Do other JRE backed languages also deal with the same?
b
@Daniel Mejia Make sure you import • the cert • any intermediate certs • the root CA cert
If you leave off any applicable bullets above, it won't work
That specific error, talking about "find a valid certificate path" usually means your missing one or both of the last two bullets
Also, make sure you've imported it into the correct trust store.
Do other JRE backed languages also deal with the same?
Yes. Really, all language ever to use certs deal with this as certs work the same regardless of how or where you are using them
✅ 1
curl is probably using your operating system's trust store, and you may have the full cert chain imported there.
Also, you posted this in #adobe but just to check-- the server making the cfhttp call is Adobe, not Lucee, right? I ask because Lucee has its own trust store separate from the JREs.
d
Correct it is Adobe
👍 1
g
Yes... CURL uses the OS'es trust store and will automatically add it if it doesn't exist. (This is why using the C++ CFX_HTTP5 module was easy. We never had to update any carts. I just worked.)
b
If you were using Lucee, you'd have the option to add it if it didn't exist
Copy code
sslcertificateinstall( <http://host.com|host.com> )
Sadly, Adobe doesn't not support such a feature.
👍🏾 1
👍 1
d
@bdw429s hmm this makes me think I’ve installed my certs via IIS correctly and incorrectly without ever noticing, plus that I have generated the cert and key for commandbox servers incorrectly. I do have an old server still running that I don’t think has ever had a problem with cfhttp(perhaps that app doesn’t need cfhttp 🤔). I’ve got some homework to do when I get in front of the computer. Thanks fellas.
@bdw429s If its valid in the browser must be good right?
b
I'm not sure what that means
Your browser does not use the same trust store as your JVM
So if you're asking if Java will always trust the same certs that your browser trusts, the answer is no.
d
Ok so in the JRE cacerts(fresh download from ortussolutions.com) "globalsign" is listed several times. The second to last certificate listed here matches my certificate. OU = globalsign root ca - r3
Copy code
Certificate fingerprint (SHA-256): 9A:29:6A:51:82:D1:D4:51:A2:E3:7F:43:9B:74:DA:AF:A2:67:52:33:29:F9:0F:9A:0D:20:07:C3:34:E2:3C:9A
c = be, o = globalsign nv-sa, cn = globalsign root e46, Oct 18, 2022, trustedCertEntry, 
Certificate fingerprint (SHA-256): CB:B9:C4:4D:84:B8:04:3E:10:50:EA:31:A6:9F:51:49:55:D7:BF:D2:E2:C6:B4:93:01:01:9A:D6:1D:9F:50:58
c = be, o = globalsign nv-sa, cn = globalsign root r46, Oct 18, 2022, trustedCertEntry, 
Certificate fingerprint (SHA-256): 4F:A3:12:6D:8D:3A:11:D1:C4:85:5A:4F:80:7C:BA:D6:CF:91:9D:3A:5A:88:B0:3B:EA:2C:63:72:D9:3C:40:C9
c = be, o = globalsign nv-sa, ou = root ca, cn = globalsign root ca, Oct 18, 2022, trustedCertEntry,
Certificate fingerprint (SHA-256): DD:69:36:FE:21:F8:F0:77:C1:23:A1:A5:21:C1:22:24:F7:22:55:B7:3E:03:A7:26:06:93:E8:A2:4B:0F:A3:89
ou = globalsign ecc root ca - r4, o = globalsign, cn = globalsign, Oct 18, 2022, trustedCertEntry, 
Certificate fingerprint (SHA-256): B0:85:D7:0B:96:4F:19:1A:73:E4:AF:0D:54:AE:7A:0E:07:AA:FD:AF:9B:71:DD:08:62:13:8A:B7:32:5A:24:A2
ou = globalsign ecc root ca - r5, o = globalsign, cn = globalsign, Oct 18, 2022, trustedCertEntry, 
Certificate fingerprint (SHA-256): 17:9F:BC:14:8A:3D:D0:0F:D2:4E:A1:34:58:CC:43:BF:A7:F5:9C:81:82:D7:83:A5:13:F6:EB:EC:10:0C:89:24
ou = globalsign root ca - r3, o = globalsign, cn = globalsign, Oct 18, 2022, trustedCertEntry, 
Certificate fingerprint (SHA-256): CB:B5:22:D7:B7:F1:27:AD:6A:01:13:86:5B:DF:1C:D4:10:2E:7D:07:59:AF:63:5A:7C:F4:72:0D:C9:63:C5:3B
ou = globalsign root ca - r6, o = globalsign, cn = globalsign, Oct 18, 2022, trustedCertEntry,
well it sort of matches. when I view my cert in the browser OU is "GlobalSign Root CA - R3". in JRE cacerts its all lowercase. Isnt this enough for JRE to trust my cert?
Actually the fingerprints do not match. my sha-256 fingerprint as shown on the browser starts with 2D 44, none in the JRE cacerts starts with that.
b
The name of a cert is not used
You'd need to compare the actual thumbprints or hashes to know if it's the same cert or not
d
yup well there it is. by fingerprint, my cert is not trusted.
b
Is the server you're hitting somewhere public were I can see it (and it's cert chain)
d
b
You have an intermediate cert in your chain FWIW
d
yup
b
Lucee has no issue hitting it (in CommandBox)
Copy code
❯ repl 'http url="<https://projectweb.psomas.com>"; echo(cfhttp.status_code)'
200
I can hit it fine from an Adobe 2021 server using cfhttp
Copy code
<cfhttp url="<https://projectweb.psomas.com>"></cfhttp>

<cfdump var="#cfhttp#">
I get the same response as Lucee
d
2018?
acf2018?
b
Dunno, I happened to have a 2021 server running, not a 2018 one, lol
This JRE
Copy code
openjdk11_jre_x64_windows_hotspot_jdk-11.0.18+10
Works on a 2018 server too
Copy code
2018.0.15+330106
Same JRE
2 Views
Open in Slack
PreviousNext
Powered by