[Talk] moving ssl site to new box/IP
Nick Simicich
talk@flux.org
Wed, 15 Nov 2006 18:24:11 -0500
On Tue, 2006-11-14 at 14:25, Larry Kagan wrote:
> Thanks. I'm sure it's documented. I just haven't come across it yet.
I looked around and found that in my Redhat system there was something
called "keytool" and that the man page included a basic explanation of
the X509 certificate - and the tool can create them and print them out.
It looks like it is mostly designed to manage self signed certs.
The question is what is in the name or alias (depending on
implementation) in the cert. Generally it is the name of the site. I
am not 100% sure but I believe that it is possible to use the IP address
of the server in the certificate - I found a reference for doing this
with "Outlook Web Access" - but this does not mean multiple certs on an
single IP address (and port) for the reasons you mentioned - but as long
as you are willing to switch internally to a port, it is not a big deal.
http://slacksite.com/apache/certificate.html explains how to set up
multiple virtual hosts on different IP addresses. But as you can see,
there is a port specified there - 443. You can just set up a different
certificate on a different port.
If you are willing to transfer from a named virtual host to your https
on your virtual host, you can run multiple ssl hosts on a single address
- by running them on different ports. Suppose you want to run both
virtsite1.example.com and virtsite2.example.org on the same system - to
handle an encrypted login, for example. Set them up as normal named
virtual hosts on port 80. Give virtsite1.example.com port 443 - its URL
would be https://virtsite1.example.com/cgi/login.pl (for example) but
the user never types that, they just click on a link to bring up the
page - and eventually it might set a cookie. The cookie would have to
be marked as not for ssl use only so that it would be transferred back,
or there could be a hidden field or a get mode URL - there are a number
of techniques that are not well secured when you are not in SSL mode
that allow you to maintain your programs' knowledge that the user has
signed in successfully. ebay and amazon do things like this - they
maintain your signin status but conceal only the password with ssl.
Someone could intercept your cookie and pretend to be you, I guess. But
when they re-verified you (amazon seems to do it every 25 seconds) the
user who was pretending to be you could not.
The http://virtsite2.example.org site would get control when it did the
named virtual host as per http 1.1. But when it wanted to transfer
control to its login routines, it would use a url like
https://virtsite2.example.org:444/cgi/login.pl
The certificate and private key can be associated with the port - just
as it is normally associated with port 443.
Again, this is an internal url that is a link - the user never types
:444 - that is buried on the web page. They will see the url on their
go line with the port, but that probably won't matter to them.
>
> On Tue, 2006-11-14 at 13:28 -0500, Danny Rathjens wrote:
> > You are right, and that is documented in many places. :)
> >
> > Larry Kagan wrote:
> > > Also on this note. I've always wondered why it was required to have a
> > > separate IP for each domain that needs ssl instead of using name-based
> > > virtual hosting.
> > >
> > > I've never seen this documented anywhere but I assume it's because name
> > > based virtual hosting is based on HTTP 1.1 where a 'host' header is sent
> > > to the server. If the header is encrypted before transmission and certs
> > > are different for each virtual host, there is no way the server process
> > > knows which host to ask for the cert to decrypt it .... so it could know
> > > which host to send the request to. Kind of a catch 22.
> > >
> > > Am I right about this? Any thoughts?
> > >
> > > Larry
> > >
> > > On Tue, 2006-11-14 at 11:29 -0500, Carl C. wrote:
> > >> ----- Original Message -----
> > >>> From: Larry Kagan
> > >>>
> > >>> I'm moving an ssl web site to another machine with another IP. Do I
> > >>> need to bother getting another cert? I can't think of a reason why I
> > >>> would but maybe one of you can.
> > >> Assuming apache and openssl, check in your httpd.conf file, you will
> > >> see you use:
> > >>
> > >> SSLCertificateFile /path/to/file/something.crt
> > >> SSLCertificateKeyFile /path/to/file/something.key
> > >>
> > >> something.crt <= crt file
> > >> something.key <= key file used to create the crt file.
> > >>
> > >> Those are required to move the SSL cert to a new server. IP address does
> > >> not matter, just those 2 files...
> > >>
> > >> Now, the trick is to go find the .csr file that was used to create your .crt file,
> > >> why? Because when you go to renew, you will need the .csr file and if you
> > >> use the old one, it's much faster/easier to renew.
> > >>
> > >> If needed, contact me off list, I sell SSL certs.
> > >> Carl
> > >> http://www.carlc.com/
> > >> _______________________________________________
> > >> Talk mailing list
> > >> Talk@flux.org
> > >> http://www.flux.org/mailman/listinfo/talk
> > >
> > > _______________________________________________
> > > Talk mailing list
> > > Talk@flux.org
> > > http://www.flux.org/mailman/listinfo/talk
> > >
> > _______________________________________________
> > Talk mailing list
> > Talk@flux.org
> > http://www.flux.org/mailman/listinfo/talk
>
> _______________________________________________
> Talk mailing list
> Talk@flux.org
> http://www.flux.org/mailman/listinfo/talk
--
Blog: http://majordomo.squawk.com/njs/blog/blogger.html
Atom: http://majordomo.squawk.com/njs/blog/atom.xml
RSS: http://majordomo.squawk.com/njs/blog/atom.rdf