Did you try MBS CURL Plugin?
There you can define ssl options like client key and what to do with certificates.
See
http://www.monkeybreadsoftware.de/xojo/plugin-curl.shtml
Thanx to Marius Dieter Noetzel:
The work around, which truly supports SNI is using
Nevertheless forcing developers to change all their code isnt acceptable
You should think about, SNI is a relatively new thing.
For a long time it was normal, that every SSL-Host needs it own IP. Since we have a shortness of IPv4 adresses there were made some curios things to better use them. SNI is one of those really curios things.
Nobody wants to support that if its not mandatory. 
But as you can see, Xojo nowadays supports it.
Don’t know why anyone hast to CHANGE anything. If the serverside is changed, it is normal to change the clientside Of course you don’t have to use virtual host based ssl-hosting…
SNI exists because TLS happens before the HTTP request. So a secure connection is made to the IP address, then the HTTP request is made to request the domain, path, and so on. There is a chicken and egg problem here, as the domain is required to make the secure connection. That’s why it used to be one certificate per address.
SNI works to solve this. I’ll admit that I don’t know how. But it does work. Old clients (such as the old HTTPSocket) don’t support it, but newer clients (such as Xojo.Net.HTTPSocket) do support it. Simple as that. Nobody is forcing you to change your code if you don’t want to. But if you want support for SNI, you do need to modernize it.
Dear [quote=310279:@Marius Dieter Noetzel][/quote],
thanx for Your thoughts. SNI has even been completely knew to me. But nevertheless we are forced to have it because the sensibility concerning secure connections (even if not really necessary) increases. As a consequence 1&1, strato now offer costless certificates, let’s encrypt too. So we terribly need it too.
The problematic thing is that the API completely changes if using the new framework: MemoryBlock, Text/String, Dictionary, POST-Parameter passing and so on. And a lot of methods, we made use off, are missing:
- how to access the underlaying TCPSocket
- how to know if connection is established
- how to know when the connection is closed
- can I xojo.net.httpsocket.send() a second time
- how to alter timeouts
- how to access all HTTP-Headers
- how to access the very first line in a response (which hasnt a header field
Sorry, that I have to state this, but this important class xojo.net.httpsocket() is terribly disappointing.
Dear [quote=310321:@Thom McGrath][/quote],
as you see from above, I have to.
Regards
Jörg
[quote=310521:@Joerg Friedrich]thanx for Your thoughts. SNI has even been completely knew to me. But nevertheless we are forced to have it because the sensibility concerning secure connections (even if not really necessary) increases. As a consequence 1&1, strato now offer costless certificates, let’s encrypt too. So we terribly need it too.
The problematic thing is that the API completely changes if using the new framework: MemoryBlock, Text/String, Dictionary, POST-Parameter passing and so on. And a lot of methods, we made use off, are missing:
how to access the underlaying TCPSocket
how to know if connection is established
how to know when the connection is closed
can I xojo.net.httpsocket.send( ) a second time
how to alter timeouts
how to access all HTTP-Headers
how to access the very first line in a response (which hasnt a header field
Sorry, that I have to state this, but this important class xojo.net.httpsocket( ) is terribly disappointing.[/quote]
Hi!
As I don’t know what you do there, I can’t talk about a way to do it with the new httpsocket.
For my needs - and I do crazy things with it 
- it is useable.
But you ever have the chance to use your own Webserver. In this case you are able to avoid virtualhost based ssl-hosting with IP sharing, because you can have multiple IPs. And then there is no Problem to use the old httpsocket with your secure website.
@Marius Dieter Noetzel
Hi, so many different applications…
Well our customers host our software on arbitrary service providers (virtual web servers at strato, 1&1 and so on). The server part is PHP. A client part is Xojo, and this specialized client talks to the server. So you can feel what all this means. And as you see, from my short list, a lot of things are missing in xojo.net.httpsocket.
Regards
Jörg
If it’s your software, running on undefined servers, you are able to write these PHP-software in a way that it does real and normal HTTP. This could be done with the new socket in a great way.
I use it all day with different projects and external apis. I really can’t see your problem.
As I said, you are free not to use these curios Webspace-Services. There are many provider that will offer you SSL-Hosting with dedicated IP, perhaps even 1und1 or strato will offer that.
So, I really can’t see your Problem…
In case you are interested:
Yes, our PHP software runs on “undefined servers” and our Xojo Software has to communicate with it (image updloads, data exchange).
API and data types between HTTPSecureSocket and xojo.Net.HTTPSocket differ in many ways. One of the problems e.a. that we take the very first line of a HTTP response as an error indication, so how to get that line from xojo.Net.HTTPSocket. We make use of synchronous calls with HTTPSecureSocket, and so on …
Of course nothing is problematic if you’ve finally found a solution to all obstacles, like the different data types and so on.
“Problematic” ist the unpaid time all this API-adaption costs. And this is it, that I’m merely blaming.
Up to now, this costs me a couple of days already. Probably there are developers out there which do it in a couple of hours. Well, it would be unnecessary, if Xojo updates more rapidly, and SNI is there for at least two years or so.
Regards.
Even if updates were more rapid, it wouldn’t make much of a difference. HTTPSocket isn’t going to be getting much of any attention. It’s an HTTP 1.0-only socket built in pure Xojo code on top of TCPSocket. HTTP is a simple protocol on the surface, but over the years has become absurd in its special case exception. When I was with the company, I was tasked with adding HTTP 1.1 support to HTTPSocket, but after reviewing the code it was decided to be too impractical.
Xojo.Net.HTTPSocket uses curl, one of the most reliable HTTP libraries available. Curl is well maintained, so updates can be frequent without requiring much of Xojo’s developer time.
This is just the way it is.
Now, one thing I would like to point out. You may or may not be aware of the advice that App.DoEvents is a very bad thing to use in a GUI application. It allows you to run an event loop inside an existing event loop, which can cause very significant problems. Well what do you think synchronous HTTPSocket requests do? Yep… DoEvents. This is why Xojo.Net.HTTPSocket does not support synchronous requests.
Of course…
But if its your Software, you can define where it is able to run. So, PHP is needed and dedicated IP is needed…
What Di you mean with that? First Line of the Body, I hope
Jepp, ok. But that is life… Some years ago nobody used SNI, today many do. Xojo has an new Class and does not support that with the old ones. For everyone who has to migrate that is absolutely uncool, but that is no Xojo-specific problem. We are dealing all day ling with old android apis, and new ones. perhaps hundreds of combinations. Terrible… You found a way, perhaps next week that one will be deprecated…
If you have problems with the new socket, feel free to ask…