Office 365: Introduzione a Microsoft Flow

Microsoft Flow è un servizio basato sul cloud che consente agli utenti di Office 365 e di Outlook.com di creare in modo semplice e pratico workflow (flussi di lavoro) in grado di automatizzare processi e attività aziendali, dispendiosi in termini di tempo, all’interno di applicazioni e servizi.

Microsoft Flow consente di creare flussi di lavoro automatizzati tra i propri servizi e applicazioni preferiti per sincronizzare i file, ottenere le notificheraccogliere dati e altro ancora. Ad esempio, è possibile registrare i tweet preferiti di un utente in un file di Excel o ricevere una notifica e-mail ogni volta che viene pubblicato un nuovo elemento in un elenco di Sharepoint ecc.

Microsoft Flow non si limita alle applicazioni in Internet. Nei flussi è possibile includere anche dati locali, ad esempio da SharePoint SQL Server.

L’elenco di applicazioni e servizi utilizzabili con Microsoft Flow è in costante espansione. Con Microsoft Flow, è possibile automatizzare attività come:


  • Rispondere istantaneamente a notifiche o messaggi e-mail di importanza critica.
  • Informare il team ogni volta che viene aggiornato un elemento di lavoro.
  • Acquisire, monitorare e seguire i nuovi clienti potenziali.


Leggi l'articolo completo in esclusiva sulla nostra community Azure Community

PASS Business Analytics Marathon (Marzo 2017)

La prossima edizione dell’evento live PASS Business Analytics Marathon si terrà mercoledì 29 marzo 2017.

Questa edizione di Business Analytics Marathon consiste di 5 webinar sui seguenti argomenti:

  • Data Driven Storytelling
  • Data Discovery
  • Power BI

L’elenco dei webinar è disponibile a questo link.

L’evento è gratuito, per effettuare la registrazione puntate il vostro browser qui.

4 motivi per adottare un approccio Cross-Cloud

Un approccio Cross-Cloud può offrire libertà, scelta e controllo sul cloud e aiutare le aziende ad accelerare il proprio percorso di digital transformation. Tuttavia, gestire in sicurezza e colmare il gap fra cloud diversi, gestendo al tempo stesso rischi, costi e sicurezza, può risultare difficile.

Richard Munro, Chief Technologist and Technical Director for vCloud Air EMEA di VMware, spiega come aiutare le aziende nella digital transformation con la Cross-Cloud Architecture di VMware. In questa serie di video, Richard illustra i vantaggi di un approccio Cross-Cloud nel supportare tutte le line of business a guidare l’innovazione e raggiungere i propri obiettivi.

Video #1: come possono le aziende modernizzare la propria infrastruttura IT con l’approccio Cross-Cloud?  

Digital transformation, cloud transformation, business transformation – da dove devono partire le aziende? Scopri come un approccio Cross-Cloud unificato e integrato all’infrastruttura IT può aiutare le organizzazioni a iniziare la propria trasformazione.

Video #2: trasformare la sicurezza: come può aiutare l’architettura Cross-Cloud? 

La sicurezza nelle moderne organizzazioni richiede una visione funzionale del profilo di rischio di ogni applicazione e la dichiarazione esatta di come ogni singola applicazione verrà protetta. Scopri come la Cross-Cloud Architecture di VMware con NSX può aiutarti a proteggere la tua azienda attraverso le piattaforme, le applicazioni e i cloud.

Video #3: come puoi abilitare il tuo Digital Workspace?

La tua forza lavoro vuole semplicità quando diventa mobile. Vuole libertà di scelta del proprio dispositivo mobile e del modo in cui accedere, ma l’IT ha ancora bisogno di qualche controllo. Ascolta cosa dice Richard Munro a proposito di come la Cross-Cloud Architecture di VMware può portare libertà e controllo nel Digital Workspace, consentendo all’IT di regolare l’ambiente senza ostacolare le persone che invece sta cercando di agevolare.

Video #4: che impatto avrà il public cloud sull’azienda del futuro?

Come può l’IT contribuire al piano 2020 di un’organizzazione? I servizi di cloud pubblico diventeranno parte di questo piano. Scopri come puoi integrare i cloud pubblici e scomporre i processi e i silos per aiutare la tua azienda a raggiungere i propri obiettivi di trasformazione.

Vuoi saperne di più su come la Cross-Cloud Architecture di VMware può aiutarti nel tuo percorso verso il cloud? Visita la nostra pagine Cross-Cloud Radius.

Vuoi iniziare il tuo percorso? Leggi il nostro eBook, “Network Virtualization for Dummies” e porta il tuo network nel futuro. Scaricalo qui.

 

 

 

 

 

Red Hat Gluster Storage 3.2

RedHat è molto nota per le sue distribuzioni e per il suo impegno nel mondo OpenStack (e più in generale nel mondo OpenSource), ma è anche molto attiva nel mondo della virtualizzazione e dello storage software defined. In particolare nell’area SDS esistono due linee di prodotto completamente differenti: RedHat Gluster Storage (in precedenza noto semplicemente come Red Hat Storage Server) fornisce una soluzione di file based storage. RedHat Chef Storage fornisce una soluzione di block e object storage. Per quanto riguarda la soluzione SDS più tradizionale, dopo l’annuncio di Red Hat Storage Server 3, ora […]

The post Red Hat Gluster Storage 3.2 appeared first on vInfrastructure Blog.

VMUGIT Meeting a Padova – 5 aprile 2017

Nuovo anno, nuovi eventi per il VMUG Italiano. Dopo alcuni mesi dalla UserCON finalmente parte una serie di meeting locali e la prima tappa del 2017 sarà (per la prima volta) Padova e precisamente il 5 aprile 2017. Sarà una giornata intera (come da tradizione) suddivisa tra sessioni tecniche (a cura di VMware e degli sponsor) con interventi ed esperienze community. In breve: Quando: 5 Aprile 2017 dalle ore 8:30 fino alle 17:30 Dove: Padova presso Hotel Crowne Plaza (Indicazioni stradali qui ) Costo: Ovviamente 0 Registrazione: Qui Agenda: ore 8:30 Registrazione ore 9:10 Welcome […]

The post VMUGIT Meeting a Padova – 5 aprile 2017 appeared first on vInfrastructure Blog.

Windows Server 2016 Highlights: Hyper-converged Cluster

Tra le novità di Windows Server 2016 spiccano quelle relative all’iperconvergenza dello storage e dell’hypervisor. Per iperconvergenza o per infrastruttura iperconvergente si intende una infrastruttura IT basata su risorse hardware offerte da un unico vendor, che integra calcolo, memorizzazione, virtualizzazione e networking. Tutte le risorse vengono gestite tramite software e l’espansione del sistema è fortemente semplificata.

Avevamo già parlato in un precedente articolo su come implementare Storage Spaces Direct. La nuova funzionalità S2D di Windows Server 2016 permette infatti di creare sistemi di storage ad alta disponibilità utilizzando dischi locali. Se poi sugli stessi nodi fisici utilizzati per creare l’infrastruttura S2D installiamo anche Hyper-V, abbiamo la possibilità di creare un cluster hyper-convergente.

Figura 1: Schema di funzionamento di una soluzione Hyper-convergente

In questo articolo vi voglio mostrare queste due funzionalità e realizzare un laboratorio di test per provare la soluzione di Hyper-convergenza offerta da Microsoft. L’obiettivo è quello di creare un cluster a 2 nodi di Hyper-V che usa Storage Spaces Direct.

Figura 2: Schema del laboratorio da realizzare

Nel mio laboratorio, realizzato su un computer con Windows 10 Anniversary Update e con il ruolo Hyper-V installato, ho creato due macchine virtuali, chiamate HV1 ed HV2, all’interno delle quali ho installato Hyper-V. Questo mi permette anche di farvi vedere come funziona la Nested Virtualization, un’altra novità disponibile in Windows 10 Anniversary Update e in Windows Server 2016.

Dopo aver creato le due macchine virtuali HV1 ed HV2 ed aver assegnato loro almeno 4GB di RAM staticamente (controllate i prerequisiti per la Nested Virtualization), ho lanciato (a VM spente) una PowerShell con privilegi elevati e ho abilitato la nested virtualization con i comandi:

#Abilitazione della Nested Virtualization

Set-VMProcessor -VMName HV1 -ExposeVirtualizationExtensions 1

Set-VMProcessor -VMName HV2 -ExposeVirtualizationExtensions 1

Figura 3: Creazione sulla macchina Windows 10 delle due macchine virtuali che faranno da host Hyper-V

Ho installato Windows Server 2016 all’interno di HV1 ed HV2 e ho abilitato il ruolo di Hyper-V. È possibile abilitare il ruolo anche utilizzando la nuova funzionalità di PowerShell Direct. Questa funzionalità permette di eseguire delle cmdlet di PowerShell dalla macchina host verso le VM, anche se le VM non hanno una scheda di rete o la scheda di rete è disconnessa. I comandi che ho usato sono:

#Installazione del ruolo Hyper-V utilizzando PowerShell Direct

$cred Get-Credential

Invoke-Command -VMName HV1 -Credential $cred -ScriptBlock {Install-WindowsFeature -Name hyper-v -IncludeManagementTools -Restart}

Invoke-Command -VMName HV2 -Credential $cred -ScriptBlock {Install-WindowsFeature -Name hyper-v -IncludeManagementTools -Restart}

Terminata l’installazione del ruolo ho provveduto a creare sullo storage locale dei due nodi Hyper-V due machine virtuali che utilizzerò come Domain controller e che ho chiamato DC1 e DC2. I due domain controller rimarranno ognuno assegnato al proprio nodo Hyper-v e verranno messi in esecuzione automatica, in modo tale che il dominio sia sempre disponibile. Poiché il servizio cluster dipende da Active Directory i due domain controller non verranno “clusterizzati”, ma rimarranno delle semplici macchine virtuali.

Figura 4: Due Domain controller annidati sugli Host virtuali HV1 ed HV2

Per far parlare tra di loro i due domain controller ho provveduto a creare sui due nodi HV1 ed HV2 un virtual switch di tipo External e successivamente ho abilitato sulle schede di rete di HV1 ed HV2 il MAC Address Spoofing dalle proprietà avanzate delle schede, in quanto le due macchine DC1 e DC2 stanno utilizzando la Nested Virtualization e senza abilitazione del MAC Address Spoofing i pacchetti di rete non riuscirebbero a superare i due Virtual Switch.

Figura 5: Abilitazione del MAC Address Spoofing

L’abilitazione del MAC Address Spoofing si può effettuare anche da PowerShell usando il comando:

#Abilitazione del MAC Address Spoofing

Get-VMNetworkAdapter -VMName HV1,HV2 | Set-VMNetworkAdapter -MacAddressSpoofing On

Dopo aver creato il dominio su DC1 e aver aggiunto DC2 come domain controller aggiuntivo, ho provveduto ad aggiungere al dominio anche i nodi HV1 ed HV2. Ho configurato anche le virtual machine DC1 e DC2 in modo tale che possano partire automaticamente quando parte l’host di virtualizzazione.

Figura 6: Autostart dei due Domanin controller DC1 e DC2

Abilitazione delle funzionalità di Storage Spaces Direct

Prima di abilitare la funzionalità S2D vi invito a dare un’occhiata agli Storage Spaces Direct hardware requirements. Tra le configurazioni supportate io ho scelto quella in cui ci sono 4 dischi SSD per ogni singolo nodo.

Drive types present

Minimum number required

All NVMe (same model)

4 NVMe

All SSD (same model)

4 SSD

NVMe + SSD

2 NVMe + 4 SSD

NVMe + HDD

2 NVMe + 4 HDD

SSD + HDD

2 SSD + 4 HDD

NVMe + SSD + HDD

2 NVMe + 4 Others

Per questo motivo ho aggiunto ad entrambi i nodi HV1 ed HV2 4 dischi da 512 GB. Per semplicità ho effettuato l’operazione lanciando dalla macchina fisica con Windows 10 eseguendo le seguenti cmdlet:

#Aggiunta dei dischi alla macchina HV1

1..4% { New-VHD -Path “C:\LAB\HV1\Virtual Hard Disks\DISCO$_.VHDX” -Dynamic –Size 512GB}

1..4% { Add-VMHardDiskDrive -VMName HV1 -ControllerType SCSI -Path “C:\LAB\HV1\Virtual Hard Disks\DISCO$_.VHDX” }

#Aggiunta dei dischi alla macchina HV2

1..4% { New-VHD -Path “C:\LAB\HV2\Virtual Hard Disks\DISCO$_.VHDX” -Dynamic –Size 512GB}

1..4% { Add-VMHardDiskDrive -VMName HV2 -ControllerType SCSI -Path “C:\LAB\HV2\Virtual Hard Disks\DISCO$_.VHDX” }

Una volta che i dischi sono stati aggiunti sarà possibile utilizzarli per attivare la funzionalità di Storage Spaces Direct. Ho installato su entrambi i nodi HV1 ed HV2 la feature di Failover Clustering e terminata l’operazione di installazione ho aperto un prompt di PowerShell con privilegi elevati su uno dei due nodi ed ho effettuato un test per verificare se fosse possibile configurare il cluster ed utilizzare S2D eseguendo la cmdlet:

#Test della configurazione dei nodi che formeranno il Cluster

Test-Cluster –Node HV1,HV2 –Include “Storage Spaces Direct”Inventory, Network“System Configuration”

Figura 7: Test della configurazione dei nodi che formeranno il Cluster

Se tutti i test sono andati a buon fine e non avete ricevuto errori potete procedere alla creazione del cluster. Non avendo ricevuto errori ho eseguito su uno dei nodi del cluster HV1 oppure HV2 la seguente cmdlet:

#Creazione di un nuovo cluster

New-Cluster -Name S2DCluster -Node HV1,HV2 –NoStorage –StaticAddress 10.10.10.100

Figura 8: Creazione del Cluster S2DCluster

Al termine della creazione del cluster ho ricevuto un warning. Controllate il contenuto del report creato e verificate che, poiché abbiamo scelto di utilizzare solo 2 nodi e di non aggiungere nessuno storage condiviso al cluster, sarà necessario configurare un witness, come mostrato in figura:

Figura 9: warning presente nel report, riferito al quorum witness

Per questo laboratorio ho preferito usare una novità del cluster di Windows Server 2016: Il Cloud Witness. Aprendo la console Failover Cluster Manager su HV1 sarà infatti possibile cambiare la modalità di quorum selezionando il nome del cluster e scegliendo More Actions à Configure Cluster Quorum Settings…

Figura 10: Modifica della funzionalità di Quorum del Cluster

Ho seguito il wizard di configurazione ed ho inserito il nome dello Storage Account e la Primary Access Key del mio account di archiviazione di Microsoft Azure. Per maggiori informazioni sugli Azure Storage Account potete visitare il link https://docs.microsoft.com/en-us/azure/storage/storage-create-storage-account

Figura 11: configurazione del Cloud Witness

Dopo aver configurato tutto a dovere 🙂 ho ottenuto una situazione come quella mostrata nella figura sotto:

Figura 12: Creazione del Cluster completata

Storage Spaces Direct

Siamo pronti per abilitare la funzionalità di Storage Spaces Direct (S2D). Ho notato che sia in Hyper-V che in Microsoft Azure i dischi collegati alle macchine riportano come MediaType il valore Unspecified. Storage Spaces Direct utilizza i due valori BusType e MediaType per configurare automaticamente lo storage pool, lo storage tiering e la cache. Infatti lanciando la cmdlet su uno dei nodi del cluster

#Verifica dei dischi collegati

Get-PhysicalDisk CanPool -EQ FT FriendlyName, BusType, MediaType, Size

ottengo il seguente risultato:

Figura 13: verifica dei dischi collegati

Per ovviare a questo problema ho abilitato Storage Spaces Direct lanciando la seguente cmdlet su uno dei nodi del cluster:

#Abilitazione di Storage Spaces Direct

Enable-ClusterS2D -CacheState Disabled -AutoConfig:0 -SkipEligibilityChecks

Rispondete Yes to All al prompt che vi apparirà, come mostrato in figura:

Figura 14: Abilitazione della funzionalità di Storage Spaces Direct

Terminata la configurazione del cluster potreste ricevere un messaggio di avviso, come mostrato in figura:

Figura 15: Abilitazione completata con warning

Se aprite il report potrete verificare che ci sarà soltanto l’avviso relativo ai dischi che non sono stati aggiunti al cluster, in quanto durante la creazione abbiamo specificato il parametro -SkipEligibilityChecks

Figura 16: Warning relativi ai dischi non aggiunti al cluster

Figura 17: Funzionalità S2D abilitata

Dopo aver abilitato la funzionalità di Storage Spaces Direct noterete che nella console del Failover Clustering sono apparsi 2 Enclosures, ognuno dei quali fa riferimento a ogni singolo nodo del cluster:

Figura 18: Enclosure con 1 dischi aggiunti al Cluster S2D

Il passaggio successivo consiste nel creare uno Storage Pool utilizzando i dischi che sono stati aggiunti al cluster attraverso gli Enclosure dei due nodi. Ho creato uno Storage Pool semplicemente eseguendo su uno dei due nodi HV1 oppure HV2 il comando:

#Creazione dello storage pool

New-StoragePool -StorageSubSystemFriendlyName *Cluster* -FriendlyName S2D -ProvisioningTypeDefault Fixed -PhysicalDisk (Get-PhysicalDisk CanPool -eq $true)

Nel mio caso ho scelto di creare uno storage pool utilizzando tutti i dischi disponibili: il risultato è mostrato in figura:

Figura 19: Storage Pool creato con tutti i dischi disponibili

Siamo pronti ora per creare un nuovo volume (da 1 TB), formattarlo REFS e trasformarlo in un Cluster Shared Volume. All’interno del volume CSV andremo poi a salvare tutte le macchine virtuali che creeremo in seguito. Per farlo basta eseguire su uno dei nodi del cluster la cmdlet:

#Creazione del nuovo volume

New-Volume -StoragePoolFriendlyName S2D* -FriendlyName VDisk01 -FileSystem CSVFS_REFS -Size 1TB

Il risultato ottenuto è quello mostrato in figura:

Figura 20: Volume da 1TB creato nel Cluster S2D

Se volete potete modificare il percorso predefiniti per il salvataggio delle macchine virtuali, eseguendo su uno dei due host HV1 oppure HV2 la seguente cmdlet:

#Modifica dei percorsi di deafult per il salvataggio delle VM

Set-VMHOST –Computername HV1,HV2 –Virtualharddiskpath ‘C:\ClusterStorage\Volume1’

Set-VMHOST –Computername HV1,HV2 -VirtualMachinePath ‘C:\ClusterStorage\Volume1’

Test del cluster Hyper-Convergente

Per testare il cluster basta utilizzare la console del Failover Cluster Manager per creare una nuova VM altamente disponibile. Ho lanciato il wizard di configurazione della nuova VM, ho inserito come percorso del salvataggio della VM il CSV creato prima e non ho avuto problemi a terminare le altre configurazioni.

Figura 21: Creazione della VM altamente disponibile

Terminato il wizard di configurazione avrete una VM altamente disponibile, che sarà visualizzata come ruolo del Cluster.

Figura 22: Nuova VM creata all’interno del cluster S2D

Provando a spegnere uno dei due nodi, nel mio caso ho spento il nodo chiamato HV2, il cluster continua a funzionare e la macchina virtuale rimane accesa.

Figura 23: Anche con un nodo spento la macchina continua a funzionare

Conclusioni

Creare un cluster Hyper-V con 2 nodi ed utilizzare la nuova funzionalità Storage Spaces Direct ci permette di creare una infrastruttura iperconvergente altamente performante e scalabile, massimizzando l’utilizzo dell’hardware. Semplicemente collegando i due nodi con schede di rete a 10 GBit abbiamo semplificato di molto la creazione del cluster e le configurazioni necessarie per renderlo operativo.

Per approfondire le configurazioni presentate in questo articolo potete visitare le pagine

Buon lavoro!

Nic

Deploy PKI in Windows Server 2016 – Parte 1 Architettura di una PKI Two-Tier

Prima di implementare una Certification Authority (CA) occorre pianificare attentamente la infrastruttura della Public Key Infrastructure (PKI) più adatta alla propria organizzazione. La prima valutazione che occorre fare è quella del numero di CA necessarie valutando le il grado di sicurezza necessario per la PKI, le necessità di alta disponibilità e il carico amministrativo necessario per la gestione.

Una CA in ambiente Windows può essere di tipo Standalone, che non richiedere l’integrazione con Active Directory, ma più complessa da amministrare in quanto non consente l’utilizzo dei modelli di certificato. In alternativa è possibile avere CA di tipo Enterprise che devono essere integrate in Active Directory, ma la cui gestione è più semplice grazie ai modelli di certificato.

Inoltre le CA si suddividono ancora in Root CA o Subordinate CA. Le Root CA sono in cima alla catena dei certificati e rilasciano i certificati alle Subordinate CA. Dal momento che il primo obbiettivo durante la pianificazione di una PKI è quello di preservarne la sicurezza evitandone la compromissione, una struttura PKI che ben si concilia con tali esigenze di sicurezza con carico amministrativo di gestione non elevato è quella Two-Tier (a due livelli) riportata nel seguente schema che verrà utilizzato come scenario di esempio.

La Root CA viene mantenuta normalmente spenta di conseguenza è preferibile che non sia integrata in Active Directory di conseguenza dovrà essere Standalone e non Enterprise, mentre la Subordinate CA a cui verrà demandano il compito di rilasciare i certificati sarà di tipo Enterprise per beneficiare dell’utilizzo dei modelli di certificato e dell’integrazione con Active Directory.

Come riportato in Optimizing the Revocation Experience conviene però gestire la Certificate Revocation List (CRL) solo tramite HTTP anziché tramite LDAP configurando un server web che si occuperà della pubblicazione evitando di assegnare tale ruolo alla Subordinate CA per ragioni di sicurezza soprattutto nel caso in cui la CRL debba essere pubblicata in Internet:

“Although AD DS enables publication of CRLs to all domain controllers in the forest, we recommend implementing HTTP instead of LDAP for revocation information publication. Only HTTP enables the use of the ETag and Cache-Control: Max-age headers providing better support for proxies and more timely revocation information. In addition, HTTP provides better heterogeneous support as HTTP is supported by most Linux, UNIX, and network device clients.”

Per ulteriori informazioni si vedano:

Installazione e configurazione del server web per la distribuzione della CRL

Prima di procedere all’installazione delle CA occorre provvedere a installare e configurare il server web che si occuperà di pubblicare la CRL e i certificati delle CA necessari nei casi in cui i certificati distribuiti non contengano la catena dei certificati.

Il server web che pubblicherà la CRL può essere un server in Workgroup per il quale è stato configurato un record DNS di tipo A relativo all’Hostname e un record DNS di tipo CANAME per evitare l’URL della CRL che sarà contenuto all’interno di ogni certificato faccia riferimento all’hostname del server sia per consentire la configurazione dell’alta disponibilità della CRL che per ragioni di sicurezza in modo da evitare di diffondere informazioni sull’infrastruttura interna.

Nello scenario di esempio saranno creati i seguenti record DNS:

Nome Tipo record DNS Valore
web01

A

10.0.0.40
crl

CNAME

Web01.ictpower.local

Aggiungere sul server il ruolo Web Server (IIS) con le impostazioni di default.

Creare una cartella dedicata a contenere le CRL e i certificati delle CA che saranno poi pubblicati dal server web, per sicurezza creare tale cartella in disco dedicato diverso dal disco di sistema. Nello scenario di esempio verrà creata la cartella CertEnroll sul volume S:. Creare sul server web un account locale che non sia membro di alcun gruppo locale a cui condividere tale cartella in scrittura, tale account verrà poi utilizzato dalle CA per caricare le CRL e i certificati delle CA in modo che il server web li possa pubblicare. Nello scenario di esempio verrà creato un account CAUser.

Configurare in IIS una Virtual Directory nel Default Web Site che punta alla cartella S:\CertEnroll con accesso anonimo, nello scenario di esempio la Virtual Directory sarà denominata CertEnroll. Per configurare l’accesso anonimo alla Virtual Directory aggiungere gli utenti ANONYMOUS LOGON e Everyone nel tab Security che per default avranno i privilegi di accesso in lettura.

Configurare delle Regole di Filtro per la Virtual Directory per consentire il double escaping per evitare che il carattere “+” che è contenuto nel URI delle delta CRL venga bloccato, a riguardo si veda AD CS: Web server should allow URI containing the “+” character to enable publishing of delta CRLs:

“The certificate revocation list (CRL) distribution point extension on this certification authority (CA) includes a URI for a remote Web server. If the Web server is running IIS 7.0 with the default configuration, then delta CRL URIs that contain the plus sign (+) will be blocked.

Request filtering in Internet Information Services (IIS) scans the content of incoming requests, which can be blocked or allowed to meet the requirements of an organization’s security policy. In IIS 7.0, the default request filtering configuration blocks requests that include the plus sign (+) in the URI. The plus sign (+) is present in the URI of delta CRLs and must be allowed by the Web server.”

Riavviare IIS tramite Internet Service Manager o tramite il comando:

iisreset /restart

Per pubblicare la CRL e il Certificato della CA non è possibile utilizzare HTTPS a riguardo si vedano i post How to Publish the CRL on a Separate Web Server (di Carol Bailey dipente Microsoft) e Designing CRL Distribution Points and Authority Information Access locations (Vadims Podāns Microsoft MVP Cloud and Datacenter Management).

“Certificate revocation lists cannot be accessed over HTTPS so to add HTTP access to one of your Internet-based site system servers would greatly increase the risk of an attacker connecting to this server.”

“NEVER use HTTPS protocol for CRT/CRL file retrieval, because CryptoAPI will permanently fail to fetch this URL.”

Blog italiani (e in italiano) nel mondo IT/ICT