Sketchup::Http::Request to sites with MTLS results in a bugsplat

Developers Ruby API
,
1

Hi all,

I’m having trouble using Sketchup::Http::Request to call websites with mTLS and it consistently result in a bugsplat.

My test code is

request = Sketchup::Http::Request.new("https://getacert.com:8443", Sketchup::Http::GET)

request.start do |request, response|
    puts "body: #{response.body}"
end

I’m using Sketchup 26.2.243 on Windows.

Thank you in advance

2

Well you are using a local variable which can quickly go out of scope and get garbage collected.

Please pay attention to the documentation for the constructor and the example showing the use of a persistent instance variable.

But still it should not be crashing SketchUp which it does even with a @request variable.

I verified with crash # 457197 on Win 11 w/ SketchUp 26.2.243

However (weirdly) an empty (or unprinatable) response body is returned in SketchUp 25.0.660 with no crash.

3

Noted about the local variable. I just wanted to verify that the issue was from the api and not my own code.

In SketchUp 24.0.594 I also get an empty response body with the status_code of 0. I was hoping upgrading would fix the issue as OpenSSL was upgraded and found this issue.

4

The BugSplat crash likely points to a native-level failure in the underlying SSL library during the mTLS handshake. Since SketchUp wraps a C++ networking layer, unhandled certificate parameters can crash the whole app instead of throwing a Ruby exception. Have you tried testing outside SketchUp to isolate if it’s strictly a Ruby API limitation?:thinking:

5

Weirdly, SketchUp 25.0.2 and SketchUp 26.2 have the same version (3.4.1) of OpenSSL.
So I am at a loss as to why the crashes happen in 26.2 and not 25.0.2.

You can expect an update to OpenSSL 3.5.6 in the next major release.

All that said, are there any HTTP headers that should be set prior to starting the request?

6

Not with this request, no. I expected to receive a “400 No required SSL certificate was sent back”.

7

So after playing around a bit I found a possible workaround to this bug for Sketchup 24.

If I make a HTMLDialog and set_url to the same base url, it does return the correct response and any call from the Sketchup::Http::Request afterwards will return a correct response.

image
image1585×999 98 KB

1.) Call the html dialog and set the url

@dlg = UI::HtmlDialog.new(dialog_title: 'Test')
@dlg.set_url("https://getacert.com:8443")
@dlg.show

2.) Wait for the dialog to respond before trying to call using Sketchup::Http::Request

@request = Sketchup::Http::Request.new('https://getacert.com:8443', Sketchup::Http::GET)

@request.start do |request, response|
  puts "body: #{response.status_code}, #{response.body}"
end
8

So SU 2024 no longer crashes? I still got a crash in SU 2026.2 (Crash #495238)

Gemini AI suggestions (... click to expand ...)

The following is suggested by Gemini AI:

The server requires a client SSL/TLS certificate (mutual TLS / mTLS) to complete the handshake, but Sketchup::Http::Request doesn’t support attaching client certificates.

To handle client certificates in SketchUp Ruby, use Ruby’s built-in net/http and openssl libraries instead of the API request object.

Solution using net/http and OpenSSL

Ruby

require 'net/http'
require 'openssl'
require 'uri'

uri = URI.parse('https://getacert.com:8443')
http = Net::HTTP.new(uri.host, uri.port)
http.use_ssl = true

# Load your client certificate and private key
cert_pem = File.read('/path/to/your/client_cert.pem')
key_pem  = File.read('/path/to/your/private_key.pem')

http.cert = OpenSSL::X509::Certificate.new(cert_pem)
http.key  = OpenSSL::PKey::RSA.new(key_pem)
            # Or OpenSSL::PKey.read(key_pem)

# Optional: Adjust verification mode if using self-signed certs
http.verify_mode = OpenSSL::SSL::VERIFY_PEER 

request = Net::HTTP::Get.new(uri.request_uri)
response = http.request(request)

puts "Status: #{response.code}"
puts "Body: #{response.body}"

Key Considerations

Chromium HTML Dialogs: UI::HtmlDialog uses embedded CEF (Chromium). Passing client certificates through UI::HtmlDialog requires installing the client certificate into the operating system’s trust store (Windows Certificate Store or macOS Keychain) so Chromium can select it during the mTLS handshake.

9

It has never crashed in su 24 or 25, you just get a status_code 0 rather than the 400.

Net http correctly returns a 400 but it’s not asynchronous.

We don’t need to pass a certificate as our server is set to optional but still that returns a 0 with Sketchup::Http::Request request rather than 200 so the workaround for us would be to call our server with the html dialog and then calls after that with Sketchup::Http::Requestafter that will work.