none
SSL FTP v IIS 7

    Dotaz

  • Zdravím,
     nainstaloval jsem si do SBS 2008 FTP pro IIS 7. Chci aby byl veškerý přenos, jak datového, tak řídícího kanálu zabezpečený, ale nedaří se mi to rozchodit. Problém je už když se má SSL použít pro zabezpečení credentials - klienti FTP prostě vyhodí hlášku:


    534 "policy requires ssl"

    V logu v intetpub je toto:

    2009-03-20 09:12:07 84.42.202.245 - 192.168.249.3 21 ControlChannelOpened - - 0 0 88b3f028-1e35-45c2-bda3-bf09b9e79948 -
    2009-03-20 09:12:08 84.42.202.245 - 192.168.249.3 21 USER admin 534 5 25 88b3f028-1e35-45c2-bda3-bf09b9e79948 -
    2009-03-20 09:12:09 84.42.202.245 - 192.168.249.3 21 ControlChannelClosed - - 0 0 88b3f028-1e35-45c2-bda3-bf09b9e79948 -

    Divné je, že přestože čas, pásmo a letní čas jsou nastaveny na serveru správně, tak log ukazuje vždy o hodinu menší čas...

    Prosím o radu, pokud se to podařilo někomu rozchodit. díky!

    sfs
    pátek 20. března 2009 9:18

Odpovědi

  • Vyřešeno,
     není to problém VMWare, ale poněkud stupidního chování FTP pro IIS 7. Musí se RUČNĚ restartovat služba FTP po nastavení portů pro pasivní FTP(po tomto zjištění jsem pro jistotu restartoval po jakémkoli nastavení). Restart počítače nestačí, IIS se sice tváří, že porty používá, ale ve skutečnosti to tak není. UFFFFF.....
     
    sfs
    • Označen jako odpověď fandango71 úterý 13. října 2009 14:39
    úterý 13. října 2009 14:39

Všechny reakce

  • Ahoj.

    Teda s tím SSL nevím. Ale ten čas bude posunutý asi proto, že to čas zapisuje zapisuje v UTC.

    JŘ - www.rezab.eu
    pátek 20. března 2009 10:11
  • Certifikat mas nastaven?
    Klient umi ssl a ma ho zapnute (JAKY klient pouzivas?)

    S casem je to jasne - viz odpoved vyse. Jediny "absolutni" cas je UTC proto se vse uklada v nem (i napr. casove udaje souboru na NTFS ...). O jeho interpretaci (prevod na mistni cas) se pak postara "klient" - v pripade textaku TY

    MP
    pátek 20. března 2009 12:26
    Moderátor
  • Ahoj,
     tento problém jsem vyřešil, bylo to opravdu ve špatném nastavení klienta. Nicméně FTP jsem stejně nerozchodil, stroj je virtualizován ve VMWare, který také dělá NAT a zřejmě si neumí poradit s pasivním FTP. Z HOSTa se na GUEST připojím bez problémů se zapnutým/vypnutým SSL/TLS, ale zvenčí to nejde, firewall na HOSTu je vypnutý, porty jsou přesměrovány. Control se otevře ale po zaslání příkazu PASV není klient schopen otevřít datový kanál(porty pro PASV jsou na FTP v IIS samozřejmě nastaveny v předem definovaném rozsahu).
     Našel jsem na VMWare foru z roku 2005 nějaký dotaz, který se týká přesně tohoto, ale je dořešen s tím, že VMWare obsahuje bug a připojení funguje opravdu jen z HOSTa. Chyba by prý měla být opravena, ale více jsem o tom nenašel.
     takže to vzdávám :-), každopádně díky za reakce

    sfs
    čtvrtek 26. března 2009 16:57
  • ftp (na to co vlastne dela) je nejhorsi protokol na svete. fxp je skvela vlastnost kterou temer nikdo nevyuziva; dani za to je ale dvojice konexi ruznymi smery s dynamickym alokovanim portu a jejich sdelovanim v payloadu. Coz pri sifrovani polozi na lopatky pripadny aplikacni modul na NATovaci

    pouzij webdav pres https jestli muzes

    MP
    čtvrtek 26. března 2009 21:02
    Moderátor
  • Vyřešeno,
     není to problém VMWare, ale poněkud stupidního chování FTP pro IIS 7. Musí se RUČNĚ restartovat služba FTP po nastavení portů pro pasivní FTP(po tomto zjištění jsem pro jistotu restartoval po jakémkoli nastavení). Restart počítače nestačí, IIS se sice tváří, že porty používá, ale ve skutečnosti to tak není. UFFFFF.....
     
    sfs
    • Označen jako odpověď fandango71 úterý 13. října 2009 14:39
    úterý 13. října 2009 14:39