New hostname…old certificate

dreamobjects

#1

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.


#2

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

#3

[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


#4

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


#5

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.


#6

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?


#7

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


#8

Yep, easier and faster. Thanks!