Wells Fargo to target midrange and mainframe

JoAnn Pierson from Wells Fargo bank called me and I am now very relieved.
This is a little long but I do have two questions at the end.  This could
help all direct connections not using their software.  The previous rants
on this list stemming indirectly from myself about not being able to go
production with the secure FTP due to password changes and logon
requirements will be resolved.  She said the reason the secure FTP is
requiring a user id and password is that their Tumbleweed software is
prompting for it.  She said the new version of Tumbleweed set for before
the end of the year will not prompt for user id and password and will use
the certificate.  For now, we can keep our password for 4 months and then
have to change it but hopefully not after that.  We would still have to
renew the certificates every year.  Initially they were going to scramble
the password since they figured the certificate would logon.  She said that
recently they have been required to make exceptions for customers who
connect directly such as midrange and mainframe customers.  She said she
has gotten complaints from others.  It works fine in test but then can't go
production and customers don't want to make it manual.  Customers who use
the Tumbleweed software don't get the logon and also connecting through
Internet Explorer as I have seen.  She said that https://sft.wellsfargo.com
is set to handle secure FTP, HTTPS, and AS2 and should be used.  The old
site limited to HTTPS was https://redxfer.wellsfargo.com.  I looked into
Scott Klement's HTTPAPI and this would probably work for the send.  But,
for automating cleared check receival, it just couldn't quite cut it (get
the list of files, receive them, delete them).  The software looks pretty
useful though.  Dave Parnin's example of using HTTPAPI for sending to Wells
Fargo was pretty good.  I already had an automated script used for our VPN
with JPMorgan Chase (Bank One) for sending and receiving files that
basically did not have to change much for Wells Fargo.  I tried the
certificates on https://redxfer.wellsfargo.com and I got a server logon I
couldn't get past.  Apparently it had different credentials than
https://sft.wellsfargo.com.
Their documentation said to use https://redxfer.wellsfargo.com for HTTPS!
But, JoAnn said that https://sft.wellsfargo.com handles HTTPS and that was
what our certificates were setup for.
My guess is that they started with HTTPS as the only option from
https://redxfer.wellsfargo.com then had to broaden and accomodate midrange
and mainframe customers into their new website and include AS2 into the
https://sft.wellsfargo.com.
So, the bottom line is that file transfer can be simplified using secure
FTP with Wells Fargo instead of HTTPS for the midrange and mainframe
community.
The only thing I'm not sure about is the impact of having a certificate
tied to the secure FTP application for all users and sessions.  I haven't
noticed anything yet and we have been sending them files.  Our setup
wouldn't affect any other types of other possible secure FTP we might
implement in the future would it?  Anyone see a problem?

Craig Strong