Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Hi,
i just though about some kind of message telling the user about the fact that if a SSL site got cloned, the new one will be non-ssl. I had a different "default" host and when tried to connect to https://cloned .. i landed there without really knowing this ..
I think that we could deal with this 2 ways: 1. let people chose the "SSL settings" in the clone dialog.(I think thats just to much work and not really neded here) 2. just give the admin a note (if he is currently clonine a SSL site) that the new site will be note SSL. If he needs SSL support he should edit the site after it got cloned ( i think that is totaly fine and will fit the needs).
I think 2. will be a easy-fix ( rather addition ) and will help users understanding the result of cloning and avoid issues.
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | ssl_do_not_clont.patch | 640 bytes | EugenMayer |
| #4 | ssl_disable.patch | 551 bytes | EugenMayer |
Comments
Comment #1
EugenMayer CreditAttribution: EugenMayer commentedmoving over to hostmaster ..beta2
Comment #2
EugenMayer CreditAttribution: EugenMayer commentedBack to provision ... due to the bug.
Well as described, cloning a SSL site would normaly lead to a non SSL site. But it seems that the backend even copys the wildcard, eventhough it will not be valid most probably ( clone -> different domain ).
I discovered this by this error during cloning:
There are no more IP addresses available on $XXXXX for the $OLDCERT certificate.
We should not try to copy any SSL certs over to the new server ( remote or not ), the site should be non-SSL and should if needed, edited later on. With the current approach, you cannot clone a site from a remote, when the site is a SSL site, if you already have SSL sites on the other hosts ( with a different SSL cert ) .. as the wrong cert is tried to get copied.
Comment #3
EugenMayer CreditAttribution: EugenMayer commentedJust verified that
Running: /var/www/drush/drush.php --context_type='site' .... --backend provision-save '@NEWALIAS' --backend
Has the wrong arguments for SSL ( the SSL cert of the old remote / site, which is doomed to fail if the new remote has own certs )
Comment #4
EugenMayer CreditAttribution: EugenMayer commentedpatch attached
Comment #5
EugenMayer CreditAttribution: EugenMayer commentedComment #6
anarcat CreditAttribution: anarcat commentedThose changes at least warrant a comment in the code explaining why we scrap the SSL config. I also feel it just works around the symptom instead of fixing the problem altogether. This error is the key here:
When you clone, you usually migrate to a new domain name, which will require a new IP... so that's an expected behavior. We certainly have a usability issue here, at the very least, and I agree that we should do our best to keep SSL when cloning, but sometimes it's just not possible.
See also #993944: ssl rollback failure.
Comment #7
EugenMayer CreditAttribution: EugenMayer commentedWell actually in my opinion you should not keep the SSL certificate at all. The reason for that is in your argumentation:
If you clone, you have a new domain.
That means the SSL cert will not be valid anymore. And even if it is a wildcard domain the base is most probably different. In my case e.g. i move the site from foo.domain1.tld to foo.domain2.tld ... both domain1 and domain2 have their own wildcard certs.
keeping the cert would never be possible, because on domain2.tld a site is already deployed, called bar.domain2.tld. Thats why the cert of the other remote cannot be installed ( 2 ssl certs on 1 IP -> not possible ).
In any ways the current implementation is buggy. Even if we stay with your argumentation, after finishing the cloning you will see that the site will be not SSL, eventhough the SSL cert has been cloned over to the server (what is useless).
I think we really have to seperate this into 2 issue:
- Should the SSL certificate be cloned at all? Should the user get asked? Should he get warned if it is not possible before cloning <- pretty complicated
- If a SSL site should be clone to an non SSL site, dont clone the SSL settings ( dont push the ssl cert on the remote ) <--- Our current case
Comment #8
anarcat CreditAttribution: anarcat commentedThe SSL cert *could* be valid. In your example, we clone from foo.example1.com to foo.example2.com. But what if we would clone from foo.example1.com to foo1.example1.com and there was a wildcard SSL for *.example1.com? We could keep the certificate.
So I think we *could* keep the cert (and we should do our best to do so). I agree with your patch as a temporary workaround, though, but it needs to have a comment in the code to indicate why we drop the cert.
Even if we can't keep the original cert, I think we can totally create a new generic one the way we do on new sites.
I agree this is a bug.
Comment #9
omega8cc CreditAttribution: omega8cc commentedI think the cloned site should never inherit any SSL stuff, as clone is always related to creating "new" site instance (or copy).
But migrate (and rename?) should inherit it, as it should be allowed during site development etc.
Comment #10
omega8cc CreditAttribution: omega8cc commentedOops, unintended change.
Comment #11
omega8cc CreditAttribution: omega8cc commentedAlso, we never know if the certificate is a wildcard cert or not, so we probably should assume it isn't, by default.
In case it is a wildcard, then the admin would need to enable SSL with the same cert on cloned site, as it requires new IP etc, so it needs more admin work anyway, besides just cloning the site.
Comment #12
EugenMayer CreditAttribution: EugenMayer commentedThere is a other bug hidden here, iam not sure i explained that properly. Even if we keep the certicate with the current code ( lets assume we could, like in your example) the site will end up beeing not SSL. That is most probably related to the site node created with wrong values ( not SSL values ). Also the configuration file will be accordingly to ssl=0, so no SSL entry ( 443 ) at all.
Reproduce by:
- create a ssl site foo.domain1.tld
- clone that site to foo1.domain1.tld
- You will end up having foo1.domain1.tld beeing not SSL
Should i create an extra issue? (i guess so)
Comment #13
EugenMayer CreditAttribution: EugenMayer commentedWell actually, whats missing here?
Comment #14
anarcat CreditAttribution: anarcat commentedI have already explained what is missing here:
Please do not change the status needlessly (ie. there was no new patch uploaded).
Comment #15
EugenMayer CreditAttribution: EugenMayer commentedcomment added
Comment #16
anarcat CreditAttribution: anarcat commentedLooks better! I think this can be committed if it's tested and works... I'll see if I can get around to that soon.
Thanks for your contribution.
Comment #17
anarcat CreditAttribution: anarcat commentedFix committed. I took the liberty of changing the comment to mark them more clearly as needs work and mention wildcards.