I am building a command line app to interface to a Bosch Smart Home Controller (SHC) using URLSession and running into a problem with certificate authentication.
Sending a request to the SHC results in a -1202 error "The certificate for this server is invalid..." which was expected as it's counted as a self-signed cert.
In URLSessionDelegate
SecTrustEvaluateWithError
returned the CFError.localisedDescription Smart Home Controller Productive Root CA” certificate is not trusted
So I used SecItemAdd
to add this certificate to my login keychain and then set it to "Always Trust", but the error still persists.
routines:OPENSSL_internal:SSLV3_ALERT_BAD_CERTIFICATE:/AppleInternal/Library/BuildRoots/a8fc4767-fd9e-11ee-8f2e-b26cde007628/Library/Caches/com.apple.xbs/Sources/boringssl/ssl/tls_record.cc:592:SSL alert number 42
I've tried various workarounds and also added an intermediate certificate received from the SHC to my login keychain with "Always Trust" set but the error persists - am I missing something?
So I used SecItemAdd to add this certificate to my login keychain and then set it to "Always Trust"
Yeah, don’t do that. To start, it doesn’t work reliably [1] but, more importantly, it seriously undermines the security of your Mac. Your goal is to write code that trusts this accessory, but marking its certificate as trusted extends that trust to all software on your Mac. That’s not good.
The correct solution is to override HTTPS server trust evaluation in your URLSession
code. I talk about this in TLS For Accessory Developers.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Last I checked it only works if the certificate claims to be a CA — that is, it contains a Basic Constraints extension — but it’s been years since I looked into this in depth, and we’ve significantly tightened up trust evaluation in that time.