none
Certificano non verificato RRS feed

  • Domanda

  • Un cliente ha acquisito una ditta estera.

    Per accedere al loro server Exchange, mi è stato mandato un certificato autofirmato, sotto forma di file PFX (con relativa password ed istruzioni di inserirlo della sezione "Computer locale/Autorità di certificazione radice attendibili")

    Eseguo le istruzioni alla lettera, il certificato apparentemente viene installato correttamente (appare prima una finestra di conferma, che avvisa che si sta per installare un certificato non verificato, chiedendo conferma... finora mi è sempre capitato coi certificati autofirmati).

    Dopo l'installazione trovo il certificato nella sezione desiderata.

    A questo punto, però, accedendo ad OWA (da qualsiasi browser) vengo comunque avvisato che il sito non è attendibile e, manco a dirlo, la configurazione dell'account Exchange in Outlook non va a buon fine (chiede a ripetizione la password dell'utente).

    Ho provato diverse combinazioni (installando il certificato in altre sezioni, scaricandolo direttamente dal sito…) man mano cancellando i precedenti da certmgr.msc, ma i browser non sono mai riusciti a vederlo correttamente

    Che altri tentativi posso fare?

    mercoledì 29 maggio 2019 21:31

Risposte

  • Oh, adesso ci siamo. Non ho mai visto funzionare un selfsigned sugli esterni, semplicemente perchè non calcola mail i SAN ma usa sempre il primo nome per l'aggancio al server.

    Quindi da fuori non andrà mai, non può. L'unico modo in cui ho visto andare i self signed è con apertura vpn client to site verso la rete e poi allora funziona. Accrocchione..ma una volta si faceva così quando non si voleva comprare il cert.

    Allora costavano davvero molto.

    ciao.

    A.


    giovedì 30 maggio 2019 14:06
    Moderatore

Tutte le risposte

  • Ciao,

    Ma quando ti connetti al server del cliente che nome usi? perchè come fai ad usare un autofirmato che ha un nome fqdn .local da fuori ed a non avere l'errore sull'owa? Di solito l'errore sull'owa con l'autofirmato non ce l'hai quando da dentro alla struttura ti connetti all'fqdn interno del server. Il nome è compreso, non da errore.

    Come fai poi ad agganciare in anywhere un client con l'autofirmato che non si può? è normale che prompti continuamente credenziali..

    Limenex. 16€ annui per un ssl. E fine degli autofirmati che non hanno più senso.

    Ciao.

    A.

    giovedì 30 maggio 2019 08:36
    Moderatore
  • Nel campo "nomi alternativi del soggetto" ci sono tutti i siti per cui il certificato deve essere valido (e di fatto sui pc dei dipendenti dell'altra ditta, funziona regolarmente, l'ho verificato di persona)

    Adesso ho provato sul pc in ufficio (Windows 7). Ho registrato il certificato nella sezione "Autorità di certificazione radice attendibili", ma il responso è sempre lo stesso (vedi figura)

    Posso aggiungere che, a differenza di molti certificati autofirmati che uso normalmente da vari clienti, che nel campo "Scopo certificato" recitano "Criteri di rilascio - Criteri di applicazione", con questo vedo un laconico "Informazioni insufficienti per verificare il certificato".

    Quindi mi viene da pensare che il certificato che mi hanno mandato (che poi è lo stesso che scarico collegandomi ad OWA) non funzioni a dovere

    giovedì 30 maggio 2019 09:29
  • I casi sono 2:

    - i dipendenti dell'altra ditta sono agganciati al dominio del server, usa il principale, i SAN sono inutili perchè trusta la CA interna..in quel caso il server.

    - il certificato che hai tu non è stato esportato correttamente, di solito se esporti non sono dei PFX, sono dei .cer, der encoded, senza chiave privata..non so perchè hai un pfx sull'autofirmato.

    Non mi vengono in mente altre spiegazioni. Se provi anche su un client qualsiasi ed anche su altri al di fuori della struttura hai la stessa problematica opto per la 2.

    Autofirmato + SAN con nomi esterni non sarebbe nemmeno da emettere...figuriamoci usarlo. 

    A.

    giovedì 30 maggio 2019 09:40
    Moderatore
  • Ovviamente non funziona su qualsiasi pc esterno lo provi.
    giovedì 30 maggio 2019 13:32
  • Oh, adesso ci siamo. Non ho mai visto funzionare un selfsigned sugli esterni, semplicemente perchè non calcola mail i SAN ma usa sempre il primo nome per l'aggancio al server.

    Quindi da fuori non andrà mai, non può. L'unico modo in cui ho visto andare i self signed è con apertura vpn client to site verso la rete e poi allora funziona. Accrocchione..ma una volta si faceva così quando non si voleva comprare il cert.

    Allora costavano davvero molto.

    ciao.

    A.


    giovedì 30 maggio 2019 14:06
    Moderatore
  • Allora dovrò convincerli a prenderne uno.

    Ho infatti notato adesso (collegandomi direttamente al loro server Exchange) che il medesimo certificato (.CER), aperto da loro mi dà determinate info, mentre copiato pari pari sul mio pc, mi dice che non può essere verificato.

    Quando usavo i certificati autofirmati (retaggio SBS), davo loro il nome primario identico all'URL che si voleva raggiungere (tipo "remote.nomedominio.it"). In questo modo, almeno finora, non ho mai avuto problemi

    giovedì 30 maggio 2019 14:19
  • si ma usavi l'autoconfig dell'sbs iniziale.

    Comunque ti dico, io uso Limenex ed SSL2BUY dove non vogliono spendere. 26$ biennale su Limenex, fino a 4 SAN, si certo non è una sicurezza importante...ma comunque sono trustati Septigo...è meglio di nulla.

    ciao!

    A

    giovedì 30 maggio 2019 14:28
    Moderatore
  • Aggiornamento. Dalla ditta estera mi hanno mandato un certificato "radice". Una volta installato anche quello, almeno OWA lo riconosce e non mi avvisa più che il sito non è sicuro.

    Outlook, invece, continua a darmi rogne, ma credo che il problema non sia più il certificato. Infatti cerca l'autodiscover.xml, mi chiede l'utente, ma poi viene dirottato su Office365. Evidentemente per qualche ragione legata alla MIA configurazione, visto che sto facendo prove sul mio PC, dove ho già diversi profili Outllook di diversa natura, vengo dirottato erroneamente su Office365 (ovviamente lì non trova l'utente del cliente)

    domenica 2 giugno 2019 10:58
  • Oh, adesso ci siamo. Non ho mai visto funzionare un selfsigned sugli esterni, semplicemente perchè non calcola mail i SAN ma usa sempre il primo nome per l'aggancio al server.

    Dipende da come fai il selfigned, volendo  puoi farlo con nomi multipli , il Subject Alternative Name

    non è una prerogativa dei certificati venduti .

    Quindi da fuori non andrà mai, non può. L'unico modo in cui ho visto andare i self signed è con apertura vpn client to site verso la rete e poi allora funziona. Accrocchione..ma una volta si faceva così quando non si voleva comprare il cert.

    Allora costavano davvero molto

    ciao.

    A.

    Sul visto o non visto che dire...

    Gastone Canali >http://www.armadillo.it


    Se alcuni post rispondono al tuo quesito(non necessariamente i miei), ricorda di contrassegnarli come risposta e non dimenticare di contrassegnare anche i post utili. GRAZIE! Ricorda di dare un occhio ai link Click Here andHere

    domenica 2 giugno 2019 14:46
    Moderatore
  • Aggiornamento. Dalla ditta estera mi hanno mandato un certificato "radice". Una volta installato anche quello, almeno OWA lo riconosce e non mi avvisa più che il sito non è sicuro.

    Outlook, invece, continua a darmi rogne, ma credo che il problema non sia più il certificato. Infatti cerca l'autodiscover.xml, mi chiede l'utente, ma poi viene dirottato su Office365. Evidentemente per qualche ragione legata alla MIA configurazione, visto che sto facendo prove sul mio PC, dove ho già diversi profili Outllook di diversa natura, vengo dirottato erroneamente su Office365 (ovviamente lì non trova l'utente del cliente)


    Quidi nel primo pfx ti avevano dato solo il certificato meno l'autorita di emissione (La CA del dominio)!

    Gastone Canali >http://www.armadillo.it


    Se alcuni post rispondono al tuo quesito(non necessariamente i miei), ricorda di contrassegnarli come risposta e non dimenticare di contrassegnare anche i post utili. GRAZIE! Ricorda di dare un occhio ai link Click Here andHere

    domenica 2 giugno 2019 14:49
    Moderatore
  • Esatto…

    mo' però sono ancora nelle curve. Sembra che Outlook, nonostante i parametri corretti (server, utente, ecc...), ad un certo punto "decida" di cercare l'utente su Office365. Si apre la finestra del login web e, ovviamente, da lì non funziona

    domenica 2 giugno 2019 17:49
  • Probabilmente hai nel registry nelle impostazioni degli autodiscover i server del 365 come primari. Era un bug di un aggioornamento degli office di Novembre che cambiava e metteva come prima ricerca quelli, morale non riuscivi ad agganciare i client. C’è da rimuovere due chiavi, togliere il profilo e rifargli fare l’aggancio. Siccome però è entrato il mio “amico” Canali nel post, lascio a lui il piacere di risolverti questa rogna, la mia nuova policy mi impone di ignorarlo, altrimenti sono sicuro che lo mando a pampogne perchè sinceramente non lo reggo più...in realtà non l’ho mai retto, ma dopo 7 anni sono agro come l’aceto Ponti. Ciao! A.
    domenica 2 giugno 2019 19:14
    Moderatore
  • Probabilmente hai nel registry nelle impostazioni degli autodiscover i server del 365 come primari. Era un bug di un aggioornamento degli office di Novembre che cambiava e metteva come prima ricerca quelli, morale non riuscivi ad agganciare i client. C’è da rimuovere due chiavi, togliere il profilo e rifargli fare l’aggancio.

    Avendo avuto lo stesso medesimo problema anche sul pc del cliente, che non aveva altri account Exchange o Office365 precedenti, concluderei che non è colpa del mio pc. Ho provato persino su un Win7 con Outlook2010, ma alla verifica dell'utente non va avanti.

    Ho cercato le chiavi a cui ti riferisci e qualcosa ho trovato, ma non risolvono nulla (anzi, in alcuni casi non mi fanno arrivare nemmeno alla prima, legittima, richiesta di password dell'utente di dominio).

    Posso concludere che c'è qualcosa di mal configurato a livello di server Exchange, che funziona solo per gli utenti che sono già nel loro dominio.

    Visto che il cliente ha comunque intenzione di abbandonare la piattaforma on premise a favore di quella online, farò in modo di accelerare al massimo questa migrazione, in modo da eliminare il problema alla radice


    martedì 4 giugno 2019 07:30