New hostname…old certificate

I got the message that objects.dreamhost.com is changing hostname. Now Transmit complains about a certificate host mismatch. I guess I could nag Support, but I’m not in a big hurry about this. I figure they’ll pop in sooner or later and reply to this message so everybody can hear about it.

Hi,

DreamObjects guy here. That you got this is really weird, because we DID roll out new certificates for the new hostname (see below for validation).

Two things comes to mind
[list=1]
[]Does Transmit correctly handle TLS SNI correctly?
[
]Does Transmit cache certificates? This has bitten some browsers before
[/list]

New hostname:

 curl https://objects-us-west-1.dream.io -I -v
* Rebuilt URL to: https://objects-us-west-1.dream.io/
*   Trying 2607:f298:4:143:acce:55:0:1...
* Connected to objects-us-west-1.dream.io (2607:f298:4:143:acce:55:0:1) port 443 (#0)
* Initializing NSS with certpath: none
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* ALPN/NPN, server did not agree to a protocol
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* 	subject: CN=*.objects-us-west-1.dream.io,OU=DreamHost Basic Wildcard SSL,OU="Provided by New Dream Network, LLC",OU=Domain Control Validated
* 	start date: Apr 12 00:00:00 2016 GMT
* 	expire date: Apr 12 23:59:59 2019 GMT
* 	common name: *.objects-us-west-1.dream.io
* 	issuer: CN=USERTrust RSA Domain Validation Secure Server CA,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US
> HEAD / HTTP/1.1
> Host: objects-us-west-1.dream.io
> User-Agent: curl/7.48.0
> Accept: */*
> 
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< x-amz-request-id: tx0000000000000013e154e-00572ac5ef-d0a5fb1-default
x-amz-request-id: tx0000000000000013e154e-00572ac5ef-d0a5fb1-default
< Content-Type: application/xml
Content-Type: application/xml
< Content-Length: 0
Content-Length: 0
< Date: Thu, 05 May 2016 04:02:55 GMT
Date: Thu, 05 May 2016 04:02:55 GMT

< 
* Connection #0 to host objects-us-west-1.dream.io left intact

Old hostname:

$ curl https://objects.dreamhost.com -I -v
* Rebuilt URL to: https://objects.dreamhost.com/
*   Trying 2607:f298:4:143:acce:55:0:1...
* Connected to objects.dreamhost.com (2607:f298:4:143:acce:55:0:1) port 443 (#0)
* Initializing NSS with certpath: none
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* ALPN/NPN, server did not agree to a protocol
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* 	subject: CN=*.objects.dreamhost.com,OU=DreamHost Basic Wildcard SSL,OU="Provided by New Dream Network, LLC",OU=Domain Control Validated
* 	start date: Apr 12 00:00:00 2016 GMT
* 	expire date: Apr 12 23:59:59 2017 GMT
* 	common name: *.objects.dreamhost.com
* 	issuer: CN=USERTrust RSA Domain Validation Secure Server CA,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US
> HEAD / HTTP/1.1
> Host: objects.dreamhost.com
> User-Agent: curl/7.48.0
> Accept: */*
> 
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< x-amz-request-id: tx0000000000000013e1fb7-00572ac624-d0a5fb1-default
x-amz-request-id: tx0000000000000013e1fb7-00572ac624-d0a5fb1-default
< Content-Type: application/xml
Content-Type: application/xml
< Content-Length: 0
Content-Length: 0
< Date: Thu, 05 May 2016 04:03:48 GMT
Date: Thu, 05 May 2016 04:03:48 GMT

< 
* Connection #0 to host objects.dreamhost.com left intact

[quote]Hi,
DreamObjects guy here. That you got this is really weird, because we DID roll out new certificates for the new hostname (see below for validation).[/quote]

Hi,
I had the same problem. My perl scripts failed with the “certificate verify failed” error if I use the new host name. I checked the wikipedia article about TLS you linked. I saw that perl needs recent version of a couple modules to supports SNI. I upgraded to the latest versions of those modules and now it works fine.

-mort

I submitted a support request with Panic/Transmit and copied robbat2’s response. Their developers are going to look into it.

We deployed a workaround yesterday so that clients that do not support SNI will now work with the new hostname (including Transmit). Let us know if you’re still having any trouble.

That worked. Thanks!

I opted to not change my trust setting because I wanted to see if/when a Transmit update would address this issue. I take it this workaround is short term until the old hostname is completely dropped, correct?

We added another IP address on which to serve the certs rather than waiting for fixes on the individual clients. Easier and faster that way!

objects-us-west-1.dream.io. 6033 IN A 64.90.32.8
objects-us-west-1.dream.io. 14400 IN AAAA 2607:f298:4:143:acce:55:2:1

Yep, easier and faster. Thanks!