I would suggest turning off SSL and seeing if you can access the site through front page. I ran into a problem when trying to edit a site in FP b/c it was case sensitive to how I created the WSS site. I was trying to open http://myserver/sites/test and it really was expecting http://myserver/sites/Test. Really strange.

FrontPage 2003 does not support SSL. Create a separate IIS Web Site host
header for your developers to use when accessing the site via FrontPage.

I tried that previously and still could not edit the site with FP
2003. Maybe I didn't set it up correctly. I added a new identity to
the existing virtual directory. What should I try differently?

I have been using FrontPage 2003 with SSL successfully for the past year or so.
No problem to report works internally and externally as well. I know some of our
clients are using successfully as well.

The only issue we had was using SSL home made certificate, you need to make sure
that your PC is fully trusting the certificate authority.

As far as support, FrontPage 2003 is supposed to support https fully and without
problem

The error you are referring too, looks like a potential misconfiguration of
IIS/Sharepoint because it should work

What version of Sharepoint are you using? We had no problems with STS 2001. The problem only exists on WSS 2003.

I will check into a potential misconfiguration of IIS/Sharepoint. Thanks.

WSS 2003, can you access your site with SSL

We can login and use the site with SSL.
The problem only occurs when we try to open the site with FP2003 or if we try to open the site as a web folder.
Microsoft has told us that FP2003 doesn't support sites with SSL certificates.
I was hoping someone may have run into this before us and might have figured out a way around this issue.
Sites on the same machine that do not have SSL cert's work just fine.

I was told the same thing by Microsoft. I understood that the only work
arounds were to create a redundant non-SSL host header or port for FrontPage
users to access the site or to create a redundant non-SSL IIS Web Site
pointed to the same site collection. But I rarely work in an SSL
environment.

Some of my students will be thrilled to hear more about how we can use
FrontPage 2003 to edit a WSS Site via SSL.

Assuming FP cannot work on a ssl  WSS Site.

I have not tried but following could be a work around.

Extend and connect another IIS Virtual Web (on the same or the other
physical server) to the same WSS content and config db and do not install
SSL on it.

You can also connect using a different (non-ssl enabled) port on the same
IIS Web Server.

If you are connecting remotely ( and have to have a secure connection) then
wrap the above over a VPN tunnel. VPN is a lower transport level encryption
and transparent to upper level application like FP.

The fact that you are getting the same error using web folders makes me thing
that this is not only a Frontpage issues.

Do you know if you are using Host Header on the web site?

Is your WSS installation in a dedicated server or is it shared with many other
IIS applications?

For our SSL sites we use dedicated IP addresses, now that's an issue for Microsoft, every time I call Redmond (via Texas->NC-> escalation) it is always an issue that they raise --- MS says that they officially do not support multiple IP addressed SharePoint sites on a server. There is an issue, yet I have never been able to determine exactly what that issue they are referring to is! We run about 40 IP addresses on our WSS server and for SSLed sites they get a unique IP address, while non-SSL we run host headered on the same server.

We did try using different
host headers, creating separate Non-SSL Virtual Directories, etc and
none worked.

We finally got things to work by doing (2) things:

We kept the SSL port as is and set the http port to 8080(instead of
the default 80).
Additionally, we edited the secure communications properties(on
Directory Security tab of virtual directory properties) and UN-
Checked the box "Require Secure channel(SSL)".

The downside is users who forget the "s" on their http no longer get
a nice error message.