The question is...can you use Self Service over HTTPS using a port of your choosing?

The answer is that you should be able to work with any port and HTTPs for Self Service. Self Service uses standard ASP pages. As long as the ASP page can be invoked the processing of the self service should not care whether the initial request was via HTTP or HTTPS and the port is not relevant.

Ports

Because a server can be running both a Web Server and Email Server and other network accessible software there has to be a way of uniquely routing requests to an individual bit of software, after all they are all on the same machine and so would share the same IP address, e.g. 192.168.1.4. The port then is an end point that indicates where a particular bit of software will be expecting to send and receive data on the machine. So the email Server will be expecting to send emails on port 25, the web server uses port 80 and so on.

As I've just said, the web server (IIS) will normally be configured to expect requests to arrive over port 80. A web server however can be configured to use another port.
In the IIS management console, under the properties for website there's an IP address (at least one) that is to be bound to the site. Click the 'Advanced' button and you'll see the option to bind to a different port.

To specify a port the request would look like:

http://www.selfservice.com:8000/mysite/

This address would try to connect to an HTTP server on port 8000 instead of the default port 80.

HTTPS

Hypertext Transfer Protocol over Secure Socket Layer or https is a way of framing an HTTP request that indicates a secure web connection. Web Requests and Server Response are encrypted and decrypted. Communication by default is assumed over port 443.

An "https": URL may specify a port; if it does not, the connection uses port 443 (unsecured HTTP typically uses port 80).

For example this COM code that instantiates the Self Service object.

CRM= eWare = Server.CreateObject("eWare.eWareSelfService");
CRM.Init(
Request.Querystring,
Request.Form,
Request.Cookies("eware"),true);

This is the code that instantiates the COM object in 'regular' application extensions.

CRM = eWare = Server.CreateObject(ClassName);
eMsg = CRM.Init(
Request.Querystring,
Request.Form,
Request.ServerVariables("HTTPS"),
Request.ServerVariables("SERVER_NAME"),
false,
Request.ServerVariables("HTTP_USER_AGENT"),
Accept);

You can see that the Regular ASP Pages include a check for HTTPS. This is because HTTPS encrypts the information sent and therefore the Sessions ID (SID) and other querystring information needs to be handled correctly.

But Self Service uses a cookie as the token of authentication and the web server will automatically handle the transfer of the information whether it is over HTTP or HTTPS. I have mentioned the use of Cookies before:
https://community.sagecrm.com/blogs/hints_tips_and_tricks/archive/2007/09/24/cookies-in-sage-crm.aspx

Something you may need to consider is if your Self Service site straddles both HTTP:// and HTTPS:// . In which case (from a cookies point of view) these are considered separate domains, so will normally not be able to access each others cookies.

You may need to add your own cookie in that case and control it so that you set the domain and path properties of the cookie. The additional cookie would contain information that needs to be shared between the HTTP:// and HTTPS:// parts of the website.

A custom cookie is written to the visitor's computer using the RESPONSE command and then retrieved from the visitor's computer using the REQUEST command.

Response.Cookies("SageCRM")("FirstName")="Simon"
Response.Cookies("SageCRM")("LastName")="Yaltoy"
Response.Cookies("CookieName").Domain = "www.panoplytech.com"
Response.Cookies("CookieName").Path = "/"

You can learn more about ASP pages can cookies here:
http://msdn.microsoft.com/en-us/library/ms524757.aspx