http://coldfusion.com logo
Join Slack
Powered by
Doing some local testing with SSL certs and such j...
# lucee
b
Doing some local testing with SSL certs and such just using self-signed certs. I can tell my browser to ignore the issues with the cert, of course. I can also add my self signed CA cert to Lucee's trust store, however if my cert was generated with a common name of 
127.0.0.1
but I'm testing a site on 
<http://site1.com|site1.com>
(local host file entries), then I can't find a way to get around this Lucee error from cfhttp
Error: Certificate for <site1.com> doesn't match any of the subject alternative names: [127.0.0.1]
I've found several hits on Google suggesting the following Java system property, but it doesn't seem to help
Copy code
-Djdk.internal.httpclient.disableHostnameVerification=true
Has anyone ever worked around this?
And yes, I COULD generate a bunch of different test certs for all the possible host names I need to test, but openssl is a pain in the butt and I have a bunch of tests that I'd like ot just be able to re-use the same test cert on, which I've always done in the browser.
z
i don't know if you can do sll certs with ip addresses, can you create one for *.localhost for testing?
b
On this topic-- people have asked for a flag in CFHTTP to totally ignore invalid certs for years while testing. Something cfx_http (or whatever it was called) allowed.
z
what's the stacktrace?
b
Doesn't show right now in this console TestBox output. Let me see if I can capture it
Here we go
Copy code
lucee.runtime.exp.NativeException: Certificate for <site1.com> doesn't match any of the subject alternative names: [127.0.0.1]
        at org.apache.http.conn.ssl.SSLConnectionSocketFactory.verifyHostname(SSLConnectionSocketFactory.java:507)
        at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:437)
        at lucee.runtime.net.http.sni.SSLConnectionSocketFactoryImpl.createLayeredSocket(SSLConnectionSocketFactoryImpl.java:36)
        at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:384)
        at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
        at lucee.runtime.net.http.sni.DefaultHttpClientConnectionOperatorImpl.connect(DefaultHttpClientConnectionOperatorImpl.java:26)
        at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:374)
        at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:393)
        at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
        at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
        at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
        at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
        at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
        at lucee.runtime.tag.Executor4.execute(Http.java:1916)
        at lucee.runtime.tag.Executor4.run(Http.java:1903)
        at lucee.commons.lang.PageContextThread.run(PageContextThread.java:25)
Caused by: javax.net.ssl.SSLPeerUnverifiedException: Certificate for <site1.com> doesn't match any of the subject alternative names: [127.0.0.1]
        ... 17 more
z
pffft,, too quick, you asked chat GPT for one!
b
It's easy to do this if I control the Java code in question, but obliviously here, I'm stuck with whatever Lucee is doing behind the scenes
Which is why it would need to be something controlled by a system prop or similar
I think that system property I found above only applies to the JDK's new HTTP client, not the apache one Lucee uses
Lots of results on Google for if I controlled how the Apache client is used https://gist.github.com/mingliangguo/c86e05a0f8a9019b281a63d151965ac7
z
d
Can you just use the Apache HttpClient directly for your needs? https://stackoverflow.com/a/38509015/16607349
b
I could, but that would suck 🙂
I use CFML because I don't want to write in Java, lol
Not sure that SNI ticket is related to my use case, Zac. I'm not using SNI on the server-- at least not in this test!
That test is later
d
From my very brief research, I'm not seeing a JVM argument that will control the behavior of the Apache HttpClient.
z
d
I also looked to see if @foundeo’s BoltHTTP support it, but it looks like it would need to be added.
z
b
I'm not seeing a JVM argument that will control the behavior of the Apache HttpClient.
Yeah, me neither 😕
f
If I recall correctly there is no easy way to do it, you have to write a custom SSLSocketFactory (or some related class) wrapper that ignores it and then tell Apache’s HTTPClient to use it, so it is possible but takes some custom java code.
b
Right, it's pretty easy if you have direct access to the http client construction
f
yeah, no easy way to do it in direct cfml I should say
b
The system property I found gave me false hope, but then I realized it didn't apply to the Apache HTTP Client 😢
f
yeah, applies to the new httpclient in Java 8+ (or maybe it was 11)
b
I'll prolly just have to generate another test cert and try and add all the hostnames I'm using as SANs
Every time I need to touch openssl to do this though, it's hours of my life down the drain, lol
d
@bdw429s I've heard nurses say the last thing most of their clients say as they're passing on is "I wish I would have spent more time with OpenSSL..." Oh wait, that doesn't sound right.
😜 3
f
have you ever tried mkcert: https://github.com/FiloSottile/mkcert
b
no, looks cool
That example in their readme looks about 100 times simpler than the 87 openssl commands to do the equivalent
One of the features I've considered adding to CommandBox is the ability of the default SSL cert to generate on-the-fly based on the host name of your test server. It's possible, but would also have lots of issues such as still needing to trust it in order to be useful.
The default SSL cert in CommandBox now is just a hard-coded one with 127.0.0.1 as the common name, but since the keys for it are basically in the repo, it's not secure in any way
f
yeah, you could probably take a look at mkcert to see how they are adding the CA cert to the browser trust store automatically… but that feature I’m not as crazy about, while it is convenient to have your own CA, that also means the CA private key is quite a critical file to your OS. I would kind of rather it just added the leaf certificate to the browser each time you generate one, but that is just me being picky
b
It's a legit concern. Trusting some rando self-signed CA means that anyone who obtains that key can create their own MITM certs which your PC will trust as well.
2 Views
Open in Slack
PreviousNext
Powered by