Filtraggio per: compliance x cancella
compliance

DigiCert will stop issuing 2-year public SSL/TLS certificates

On August 27, 2020 5:59 pm MDT (23:59 UTC), DigiCert will stop issuing 2-year public SSL/TLS certificates to prepare for the industry changes to the maximum allowed validity for public SSL/TLS certificates.

After the August 27 deadline, you can only purchase 1-year public SSL/TLS certificates.

What do I need to do?

To ensure you get needed 2-year public SSL/TLS certificates before the August 27 deadline:

  • Take inventory of needed 2-year certificates—new and renewals.
  • Order any 2-year certificates that you need before August 13.
  • Respond to any domain and organization validation requests in a timely manner.

To learn how this change will affect pending certificate orders, reissues, and duplicates, see End of 2-Year DV, OV, and EV public SSL/TLS certificates.

DigiCert Services API

For those using the DigiCert Services API, you'll need to update your API workflows to account for the new maximum certificate validity of 397 days for requests placed after the August 27 deadline. See Services API.

After August 27, 2020

After August 27, you can only purchase 1-year public SSL/TLS certificates. However, to maximize your SSL/TLS coverage, purchase your new certificates with a DigiCert® Multi-year Plan. See Multi-year Plans.

Why is DigiCert making this change?

On September 1, 2020, the industry says good-bye to 2-year certificates. Going forward Certificate Authorities (CA) can only issue public DV, OV, and EV SSL/TLS certificates with a maximum validity of 398 days (approximately 13 months).

DigiCert will implement a 397-day maximum validity for all public SSL/TLS certificates as a safeguard to account for time zone differences and to avoid issuing a public SSL/TLS certificate that exceeds the new 398-day maximum validity requirement.

Check out our blog to learn more about the transition to 1-year public SSL/TLS certificates: One-Year Public-Trust SSL Certificates: DigiCert’s Here to Help.

new

Multi-year Plans now available

We are happy to announce that Multi-year Plans are now available in CertCentral and CertCentral Partners.

DigiCert® Multi-year Plans allow you to pay a single discounted price for up to six years of SSL/TLS certificate coverage. With Multi-year Plans, you pick the SSL/TLS certificate, the certificate validity (1 or 2 years), and the duration of coverage you want (up to six years). Until the plan expires, you reissue your certificate at no cost each time it reaches the end of its validity period.

Note: This product is not available for CertCentral Enterprise accounts.

The maximum validity of an SSL/TLS certificate is 825 days (397 days after September 1, 2020). When the active certificate for a Multi-year Plan is about to expire, you reissue the certificate to maintain your SSL/TLS coverage.

compliance

Browser support for TLS 1.0 and 1.1 has ended

The four major browsers no longer support Transport Layer Security (TLS) 1.0 and 1.1.

What you need to know

This change doesn't affect your DigiCert certificates. Your certificates continue to work as they always have.

This change affects browser-dependent services and applications relying on TLS 1.0 or 1.1. Now that browser support for TLS 1.0 and 1.1 has ended, any out-of-date systems will be unable to make HTTPS connections.

What you need to do

If you are affected by this change and your system supports more recent versions of the TLS protocol, upgrade your server configuration as soon as you can to TLS 1.2 or TLS 1.3.

If you do not upgrade to TLS 1.2 or 1.3, your webserver, system, or agent will not be able to use HTTPS to securely communicate with the certificate.

Browser TLS 1.0/1.1 deprecation information

Firefox 78, released June 30, 2020

Safari 13.1, released March 24, 2020

Chrome 84, released July 21, 2020

Edge v84, released 7/16/2020

Helpful resources

With so many unique systems relying on TLS, we can't cover all upgrade paths, but here are a few references that may help:

enhancement

CertCentral Services API: Updated error message documentation

In the Services API documentation, we've updated the Errors page to include descriptions for error messages related to:

  • Immediate DV certificate issuance
  • Domain control validation (DCV)
  • Certificate Authority Authorization (CAA) resource record checks

Earlier this year, we improved the APIs for DV certificate orders and DCV requests to provide more detailed error messages when DCV, file authorization, DNS lookups, or CAA resource record checks fail. Now, when you receive one of these error messages, check the Errors page for additional troubleshooting information.

For more information:

compliance

Termina il supporto browser per TLS 1.0 e 1.1

Nel 2020, i quattro browser principali termineranno il supporto per Transport Layer Security (TLS) 1.0 e 1.1.

Questa modifica non interessa i tuoi certificati DigiCert. I tuoi certificati continueranno a funzionare come sempre.

Cosa devi sapere

Questa modifica interessa i servizi e le applicazioni che dipendono da browser e che si affidano a TLS 1.0 o 1.1. Una volta che il supporto del browser per TLS 1.0 o 1.1 termina, questi sistemi obsoleti non potranno realizzare delle connessioni HTTPS.

Cosa devi fare

Se sei interessato da questa modifica, programma di attivare o eseguire l’upgrade a TLS 1.2 o TLS 1.3 adesso. Prenditi il tempo adeguato per risolvere qualsiasi problema. Prima di iniziare, verifica di individuare tutti i sistemi che potrebbero usare TLS 1.0 o 1.1.

Non dimenticare di controllare i server web come Apache o Microsoft IIS, .NET Framework, agenti di monitoraggio server e altre applicazioni commerce che potrebbero usarlo.

Risorse utili

Con così tanti tipi di sistemi diversi che si affidano a TLS, non possiamo coprire tutti i percorsi di upgrade disponibili, ma ecco alcuni riferimenti che possono aiutarti:

compliance

Microsoft sta sospendendo l’assistenza per le firme digitali del pacchetto driver kernel-mode di terze parti

Il processo per firmare i pacchetti driver kernel-mode è cambiato. A partire dal 2021, Microsoft sarà l’unico provider di firme codice kernel-mode di produzione. D’ora in poi dovrai iniziare a seguire le istruzioni aggiornate di Microsoft per firmare qualsiasi nuovo pacchetto driver kernel-mode. Consulta Centri partner per hardware Windows.

Cosa sta facendo DigiCert?

Come prima fase in questo processo di interruzione, DigiCert ha rimosso l’opzione della piattaforma Microsoft Kernel-Mode Code dai moduli di richiesta certificati di firma codice: nuovo, riemissione e rinnovo.

Ciò significa che andando avanti, non puoi più ordinare, rimettere o rinnovare un certificato di firma codice per la piattaforma kernel-mode.

In che modo ciò interessa il mio certificato di firma codice kernel-mode esistente?

Puoi continuare a usare i tuoi certificati esistenti per firmare i pacchetti driver Kernel-Mode finché il principale con firma incrociata a cui è concatenato non scade. I certificati principali con firma incrociata di marchio DigiCert scadono nel 2021.

Per ulteriori dettagli, consulta il nostro articolo di knowledge, Microsoft interrompe il supporto per i certificati principali con firma incrociata con le capacità di firma kernel-mode.

compliance

Nuovi requisiti di conformità Apple per i certificati SSL privati

Di recente Apple ha annunciato alcuni nuovi requisiti di sicurezza per i certificati SSL/TLS che entreranno in vigore con il rilascio di iOS 13 e macOS 10.15. Questi requisiti interessano i certificati privati emessi dopo il 1° luglio 2019.

Per i tuoi certificati DigiCert SSL/TLS pubblici, non devi compiere alcuna operazione.

I certificati DigiCert SSL/TLS pubblici soddisfano già tutti questi requisiti di sicurezza. I tuoi certificati SSL/TLS pubblici non sono interessati da questi nuovi requisiti e saranno attendibili in iOS 13 e macOS 10.15.

Cosa c’è di nuovo?

Apple implementa altri requisiti di sicurezza per tutti i certificati SSL/TLS che, per progettazione, interessano i certificati SSL/TLS privati. Consulta Requisiti per i certificati attendibili in iOS 13 e macOS 10.15.

I certificati DigiCert SSL/TLS privati soddisfano questi requisiti, se emessi dagli amministratori account in base ai requisiti per i certificati pubblici.

Di seguito abbiamo fornito un elenco dei requisiti che possono interessare i certificati SSL/TLS privati. Il rilascio di queste versioni di sistemi operativi Apple è previsto per l’autunno di quest’anno. Ciò significa che ti devi preparare adesso.

I nuovi requisiti di certificati SSL/TLS privati:

  • Devi usare un algoritmo della famiglia SHA-2 nell’algoritmo della firma. I certificati SSL/TLS con firma SHA-1 non sono più attendibili.
  • Devi avere un periodo di validità di 825 giorni o meno. I certificati SSL/TLS con una validità superiore a 825 giorni non sono più attendibili.

Cosa puoi fare?

Se è necessaria l’attendibilità Apple iOS e macOS per i tuoi certificati SSL/TLS privati, verifica che tutti i requisiti dei certificati SSL/TLS privati emessi dopo il 1° luglio 2019 soddisfino i nuovi requisiti. Se trovi un certificato che non soddisfa questi requisiti, dovrai eseguire presti queste operazioni:

compliance

Firefox termina il supporto per la generazione di chiavi

Con il rilascio di Firefox 69, Firefox non supporterà più Keygen. Firefox utilizza Keygen per facilitate facilitare la generazione di materiale per chiavi per l’invio di chiavi pubbliche quando si generano certificati di firma codice, Client e SMIME nel browser.

Nota: Chrome ha già interrotto il supporto per la generazione di chiavi, mentre Edge e Opera non l’hanno mai supportata.

In che modo ti interessa la questione?

Dopo che DigiCert emette i tuoi certificati di firma codice, Client o SMIME, ti invieremo un’e-mail con un link per creare e installare il tuo certificato.

Una volta rilasciato Firefox 69, puoi usare solo due browser per generare questi certificati: Internet Explorer e Safari. Se la policy aziendale richiede l’uso di Firefox, puoi usare Firefox ESR o una copia esportabile di Firefox.

Per ulteriori informazioni, consulta Interruzione del supporto Keygen con Firefox 69.

Consigli pratici

  • Puoi ancora usare Firefox 69 per l’autenticazione client. Prima di tutto, genera il certificato SMIME in IE 11 o Safari. Poi, importa il certificato SMIME in Firefox.
  • Per bypassare la generazione di certificati di firma codice, Client o SMIME nel tuo browser, genera e invia una CSR con l’ordine. Al poso di un link, DigiCert ti invierà un’e-mail con il tuo certificato allegato.
new

Abbiamo aggiunto un nuovo stato, Inviato per e-mail al destinatario, Alle pagine Ordini e Dettagli ordine, per gli ordini di certificato di firma codice e client, consentendoti di identificare più facilmente dove si trovano questi ordini nel processo di emissione.

Questo nuovo stato indica che DigiCert ha convalidato l’ordine e che il certificato è in attesa che l’utente/destinatario dell’e-mail lo generi in uno dei browser supportati: IE 11, Safari, Firefox 68, e Firefox esportabile.

(Nel menu della barra laterale, fai clic su Certificati > Ordini. Dopodiché, nella pagina Ordini, fai clic sul numero d’ordine per l’ordine di certificato di firma codice o client.)

enhancement

Abbiamo aggiornato i nostri processi di riemissione certificati Convalida estesa (EV), Firma codice (CS) e Firma documento (DS), consentendoti di riemettere questi certificati senza revocare automaticamente il certificato attuale (certificato originale o precedentemente riemesso).

Nota: Se non ti serve il certificato attuale (certificato originale o precedentemente riemesso), dovrai contattare l’assistenza in modo che possa revocarlo per te.

Ora, la prossima volta che riemetti un certificato EV, CS o DS, puoi mantenere attivo il certificato emesso in precedenza fino al suo periodo di validità attuale (o per tutto il tempo che ti serve).

compliance

Promemoria della conformità con gli standard di settore

Per i certificati pubblici e privati, le autorità di certificazione (CA) non accettano abbreviazioni per queste parti di un indirizzo nei tuoi ordini di certificato o nelle tue richieste di preconvalida organizzazione:

  • Stato o Provincia*
  • Città o Località*

*Si applica all’organizzazione e agli indirizzi di giurisdizione.

new

Abbiamo semplificato la definizione dell’ambito di convalida dominio per il tuo account quando invii i tuoi domini per la convalida (preconvalida o tramite ordini di certificato).

Nella pagina Preferenze divisioni, abbiamo aggiunto due opzioni dell’ambito di convalida dominio:

  • Invia nomi dominio esatti per la convalida
    Con questa opzione, le richieste per nuovi domini vengono inviate per la convalida esattamente come indicate (ad es. la richiesta per sub.esempio.com viene inviata per la convalida esattamente come sub.esempio.com). Funziona anche la convalida per il dominio di “livello maggiore” (ad es. esempio.com). Si tratta del comportamento predefinito per CertCentral.
  • Limita la convalida solo al dominio base
    Questa opzione ti consente di limitare la convalida dominio al dominio base (ad es. esempio.com). Per le richieste che includono nuovi sottodomini (ad es. sub.esempio.com), accettiamo solo la convalida dominio per la base dominio (ad es. esempio.com). La convalida per il sottodominio (ad es. sub.esempio.com) non funzionerà.

Per configurare l’ambito di convalida dominio per il tuo account, nel menu della barra laterale, fai clic su Impostazioni > Preferenze. Nella pagina Preferenze divisioni, espandi Impostazioni avanzate. Nella sezione Convalida del controllo del dominio (DCV), sotto Ambito di convalida dominio, vedrai le nuove impostazioni.

fix

Abbiamo risolto un bug in cui stavamo limitando il numero massimo consentito di SAN a 10 nella riemissione dei certificati SSL Wildcard e degli ordini di nuovi certificati.

Ora, quando riemetti o ordini un nuovo certificato SSL Wildcard, puoi aggiungere fino a 250 SAN.

compliance

Modifica degli standard di settore

A partire dal 31 luglio 2019 (19:30 UTC), devi usare il metodo DCV Dimostrazione pratica HTTP per dimostrare il controllo sugli indirizzi IP indicati sui tuoi ordini di certificato.

Per ulteriori informazioni sul metodo DCV Dimostrazione pratica HTTP, fai riferimento a queste istruzioni:

Attualmente, gli standard di settore vengono usati per consentirti di usare altri metodi DCV per dimostrare il controllo sul tuo indirizzo IP. Tuttavia, con il passaggio della Scheda SC7, le regolazioni per la convalida degli indirizzi IP sono cambiate.

Scheda SC7: Aggiorna i metodi di convalida dell’indirizzo IP

Questa scheda ridefinisce i processi consentiti e le procedure per la convalida del controllo del cliente di un indirizzo IP elencato in un certificato. Le modifiche della conformità per la Scheda SC7 entrano in vigore il 31 luglio 2019 (19:30 UTC).

Per rimanere conformi, a partire dal 31 luglio 2019 (19:30 UTC), DigiCert consente ai clienti di usare solo il metodo DCV Dimostrazione pratica HTTP per convalidare i loro indirizzi IP.

Rimozione del supporto per IPv6

A partire dal 31 luglio 2019 (19:30 UTC), DigiCert ha rimosso il supporto per i certificati per gli indirizzi IPv6. A causa delle limitazioni server, DigiCert non è in grado di arrivare all’indirizzo IPv6 per verificare il file che si trova sul sito web del cliente per il metodo DCV Dimostrazione pratica HTTP.

enhancement

Abbiamo aggiornato le Impostazioni federazione CertCentral SAML, consentendoti di evitare che il tuo Nome federazione venga visualizzato nell’elenco degli IdP nelle pagine Selezione IdP SAML Single Sign-On e Selezione IdP delle richieste di certificato SAML.

Ora, nella pagina Impostazioni federazione, sotto Metadati di IDP, abbiamo aggiunto l’opzione Includi nome federazione. Se desideri evitare che il tuo Nome federazione venga visualizzato nell’elenco degli IdP nella pagina Selezione IdP, deseleziona Aggiungi il mio nome federazione all’elenco degli IdP.

new

I certificati Secure Site Pro TLS/SSL sono disponibili in CertCentral. Con Secure Site Pro, l’addebito avviene per dominio; non sono previsti costi per il certificato base. Se aggiungi un dominio, il costo sarà per un dominio. Se ti servono nove domini, il costo sarà per nove domini. Proteggi fino a 250 domini con un certificato.

Offriamo due tipi di certificati Secure Site Pro, uno per i certificati OV e l’altro per i certificati EV.

  • Secure Site Pro SSL
    Richiedi il certificato OV che soddisfa le tue esigenze. Fornisci la crittografia e l’autenticazione per un dominio, un dominio wildcard e tutti i sottodomini, oppure usa i Nomi alternativi soggetto (SAN) per proteggere più domini e domini wildcard con un certificato.
  • Secure Site Pro EV SSL
    Richiedi il certificato di convalida estesa che soddisfa le tue esigenze. Fornisci la crittografia e l’autenticazione per proteggere un dominio oppure usa i Nomi alternativi soggetto (SAN) per proteggere più siti (nomi di dominio completamente qualificati) con un certificato.

Vantaggi inclusi con ogni certificato Secure Site Pro

Ogni certificato Secure Site Pro include – senza costi aggiuntivi – primo accesso alle future funzioni aggiuntive premium per CertCentral (ad es., monitoraggio del registro CT e gestione convalide).

Altri vantaggi includono:

  • Convalida priorità
  • Assistenza prioritaria
  • Due sigilli sito premium
  • Controllo malware
  • Garanzie leader nel settore

Per attivare i certificati Secure Site Pro per il tuo account CertCentral, contatta il tuo account manager o il nostro team di assistenza.

Per scoprire ulteriori informazioni sui nostri certificati Secure Site Pro, consulta DigiCert Secure Site Pro.

compliance

I certificati SSL pubblici non possono più proteggere i nomi dominio con trattini bassi ("_"). Tutti i certificati precedentemente emessi con trattini bassi nei nomi dominio devono scadere prima di questa data.

Nota: La soluzione con trattino basso preferita è rinominare i nomi host (FQDN) che contengono i trattini bassi e sostituire i certificati. Tuttavia, per quelle situazioni in cui non è possibile rinominare, puoi usare i certificati privati e, in alcuni casi, puoi usare un certificato wildcard che protegge l’intero dominio.

Per ulteriori dettagli, consulta Eliminazione dei trattini bassi nei nomi dominio.

compliance

Requisiti standard di settore per l’inclusione dell’estensione CanSignHttpExchanges in un certificato ECC SSL/TLS:

  • Record risorsa CAA per il dominio che include il parametro "cansignhttpexchanges=yes" *
  • Coppia di chiavi Elliptic Curve Cryptography (ECC)
  • Estensione CanSignHttpExchanges
  • Validità massima di 90 giorni*
  • Usato solo per lo Scambio HTTP firmati

*Nota: Questi requisiti entrano in vigore il 1° maggio 2019. L’estensione Scambi HTTP firmati è in fase di sviluppo attivo. Ci potrebbero essere altre modifiche ai requisiti unitamente allo sviluppo industriale.

Il requisito di validità certificato massima di 90 giorni non interessa i certificati emessi prima del 1° maggio 2019. Nota: il certificato riemesso sarà troncato a 90 giorni dal momento della riemissione. Tuttavia, puoi continuare a riemettere il certificato per il periodo di validità acquistato intero.

Estensione CanSignHttpExchanges

Di recente, abbiamo aggiunto un nuovo profilo certificato, Scambi HTTP firmati per risolvere il problema di visualizzazione dell’URL AMP URL dove il tuo marchio non veniva visualizzato nella barra degli indirizzi. Consulta Visualizza URL AMP migliori con Scambi firmati.

Questo nuovo profilo ti consente di includere l’estensione CanSignHttpExchanges nei certificati SSL/TLS OV ed EV. Una volta abilitata per il tuo account, l’opzione Includi l’estensione CanSignHttpExchanges nel certificato compare sui tuoi moduli di ordine certificato SSL/TLS OV ed EV sotto Opzioni certificato aggiuntive. Consulta Richiedi il tuo certificato Scambi HTTP firmati.

Per abilitare questo profilo certificato per il tuo account, contatta il tuo account manager o il nostro team di assistenza.

compliance

Le CA non possono più emettere certificati SSL pubblici di 30 giorni contenenti trattini bassi nei nomi dominio (nomi comuni e nomi alternativi soggetto).

Nota: La soluzione con trattino basso preferita è rinominare i nomi host (FQDN) che contengono i trattini bassi e sostituire i certificati. Tuttavia, per quelle situazioni in cui non è possibile rinominare, puoi usare i certificati privati e, in alcuni casi, puoi usare un certificato wildcard che protegge l’intero dominio.

Per ulteriori dettagli, consulta Eliminazione dei trattini bassi nei nomi dominio.

compliance

Ultimo giorno in cui puoi ordinare certificati SSL pubblici di 30 giorni contenenti trattini bassi nei nomi dominio (nomi comuni e nomi alternativi soggetto) da qualsiasi CA.

Nota: La soluzione con trattino basso preferita è rinominare i nomi host (FQDN) che contengono i trattini bassi e sostituire i certificati. Tuttavia, per quelle situazioni in cui non è possibile rinominare, puoi usare i certificati privati e, in alcuni casi, puoi usare un certificato wildcard che protegge l’intero dominio.

Per ulteriori dettagli, consulta Eliminazione dei trattini bassi nei nomi dominio.

compliance

Non devi eseguire alcuna azione.

A partire dal 13 febbraio 2019, DigiCert non emette più certificati ECC TLS/SSL (ad es. certificati con chiavi ECDSA) con la coppia curva-hash P-384 con SHA-2 512 (SHA-512). Questa coppia curva-hash non è conforme alla politica sullo store principale di Mozilla.

La politica sullo store principale di Mozilla supporta solo queste coppie curva-hash:

  • P‐256 con SHA-256
  • P‐384 con SHA-384

Nota: Hai un certificato con una coppia curva-hash P-384 con SHA-512? Non ti preoccupare. Quando è il momento di rinnovare il certificato, sarà emesso automaticamente usando una coppia curva-hash supportata.

compliance

Le autorità di certificazione (CA) hanno revocato tutti i certificati SSL pubblici contenenti trattini bassi (nel nome comune e nei nomi alternativi soggetto) con una validità massima di più di 30 giorni entro la fine della giornata (UTC).

Se avevi un certificato SSL con una validità totale di 31 giorni o più (che include tutti i certificati da 1 anno, 2 anni e 3 anni) che è scaduto dopo il 14 gennaio 2019, la CA che ha emesso il certificato doveva revocarlo.

Per ulteriori dettagli, consulta Eliminazione dei trattini bassi nei nomi dominio.

compliance

DigiCert ha iniziato ad emettere i certificati SSL pubblici contenenti trattini bassi per un periodo di tempo limitato.

  • Validità massima di 30 giorni per i certificati SSL pubblici contenenti trattini bassi nei nomi dominio.
  • I trattini bassi non devono essere nel dominio base ("example_domain.com" non è consentito).
  • I trattini bassi non devono essere nell'etichetta dominio più sinistra ("_esempio.dominio.com" e "example_domain.esempio.com" non sono consentiti).

Per ulteriori dettagli, consulta Eliminazione dei trattini bassi nei nomi dominio.

new

Nel menu in alto, abbiamo aggiunto due nuove opzioni di supporto (icone telefono e chat), facilitando così il contatto con l’assistenza da CertCentral (tramite e-mail, chat o telefono).

L’icona del telefono ti fornisce le opzioni e-mail e telefono. L’icona della chat ti fornisce una finestra di chat in cui puoi iniziare una conversazione con uno dei nostri membri del team di assistenza dedicato.

enhancement

Abbiamo migliorato il menu della barra laterale, consentendoti di vedere facilmente l’opzione di menu per le pagine che visiti. Ora, quando visiti una pagina in CertCentral, l’opzione di menu per quella pagina avrà una barra blu orizzontale accanto.

fix

Abbiamo risolto un bug nella funzione Aggiungi organizzazione sui moduli di richiesta certificato SSL/TLS dove lo stato di convalida (EV e OV convalidato) non era inclusi per le nuove organizzazioni aggiunte e convalidate come parte dell’ordine di certificato.

Ora, le nuove organizzazioni aggiunte quando si ordina un certificato SSL mostreranno uno stato Convalidato.

Nota: Lo stato di convalida dell’organizzazione non viene visualizzato finché non abbiamo completamente convalidato l’organizzazione.

compliance

Modifica della conformità con gli standard di settore. Per i certificati attendibili pubblicamente, i trattini bassi ( _ ) non possono più essere inclusi nei sottodomini. RFC 5280 ora rinforzato anche per i sottodomini.

Consulta Certificati attendibili pubblicamente – Dati inseriti che violano gli standard di settore.

Agosto 1, 2018

compliance

Cambiati gli standard di settore e rimossi due metodi di convalida controllo dominio (DCV) dai requisiti base (BR).

A partire dal 1° agosto 2018, le autorità di certificazione non possono più usare i seguenti metodi di convalida controllo dominio (DCV):

  • 3.2.2.4.1 Convalida del richiedente come contatto dominio
    Questo metodo ha consentito ad una CA di convalidare il controllo del richiedente certificato su un dominio su un ordine di certificato SSL/TLS verificando che il richiedente è direttamente il contatto dominio con il Registrar nome dominio.
  • 3.2.2.4.5 Documento di autorizzazione dominio
    Questo metodo ha consentito ad una CA di convalidare il controllo del richiedente certificato su un dominio su un ordine di certificato SSL/TLS usando la conferma dell’autorità del richiedente di ordinare un certificato per detto dominio secondo quanto contenuto in un Documento di autorizzazione dominio.
    Consulta Scheda 218: Rimuovi metodi di convalida 1 e 5.

Per scoprire ulteriori informazioni su alcuni dei metodi DCV disponibili, consulta Metodi di convalida del controllo del dominio (DCV).

Maggio 25, 2018

compliance

Conformità DigiCert con RGPD

Il Regolamento generale sulla protezione dei dati (RGPD) è una legge dell’Unione Europea sulla protezione dei dati e sulla privacy per tutte le persone che vivono nell’UE. Lo scopo principale è fornire ai cittadini e ai residenti dell’UE un maggiore controllo sui dati personali e semplificare l’ambiente regolatorio per le attività internazionali unificando le norme all’interno dell’UE. Il RGPD è entrato in vigore il 25 maggio 2018. Altri dettagli »

Dichiarazione DigiCert

DigiCert si è impegnata a capire e rispettare il RGPD. Eravamo in linea con il RGPD quando è entrato in vigore il 25 maggio 2018. Consulta Soddisfare il Regolamento generale sulla protezione dei dati (RGPD).

compliance

Impatto del RGPD sulla convalida controllo dominio (DCV) dell’e-mail basata su WHOIS

Il Regolamento generale europeo sulla protezione dei dati (RGPD) è entrato in vigore il 25 maggio 2018. Il RGPD richiede la protezione dei dati per le persone naturali (non le entità aziendali) che risiedono nell’Unione Europea (UE).

DigiCert ha collaborato con ICANN per mantenere disponibili le informazioni WHOIS. ICANN ha annunciato che continua a richiedere registri e registrar per inviare informazioni a WHOIS, con qualche modifica per sistemare il RGPD. Consulta Nota su WHOIS, sul RGPD e sulla convalida dominio.

Ti affidi alla convalida dominio e-mail basata su WHOIS?

Consulta il tuo registrar dominio per scoprire se viene utilizzata un’e-mail resa anonima o un modulo web come modo che hanno le CA per accedere ai dati WHOIS come parte della loro conformità al RGPD.

Per il processo di convalida più efficace, comunica al tuo registrar che vuoi che continuino a usare il tuoi record pubblicati completi o che utilizzino un indirizzo e-mail reso anonimo per i tuoi domini. L’uso di queste opzioni garantirà un impatto minimo o assente sui nostri processi di convalida.

Il tuo registrar usa un’e-mail resa anonima o una modulo web come modo che hanno le CA per accedere ai dati WHOIS? Se sì, possiamo inviare l’e-mail DCV agli indirizzi elencati nel record WHOIS.

Il tuo registrar maschera o rimuove gli indirizzi e-mail? Se sì, dovrai usare uno degli altri metodi per dimostrare il controllo sui tuoi domini:

  • E-mail costruita
  • DNS TXT
  • DNS CNAME
  • Dimostrazione pratica HTTP

Per maggiori informazioni sugli indirizzi e-mail costruiti e altri metodi DCV alternativi, consulta Metodi di convalida del controllo del dominio (DCV).

Maggio 10, 2018

compliance

Gli standard del settore consentono ad un’autorità di certificazione (CA) di emettere un certificato SSL/TLS per un dominio che ha solo dei record CAA che non contengono tag di proprietà "emissione"/"issuewild".

Quando una CA effettua una query su RR CAA di un dominio e trova i record senza alcun tag di proprietà "emissione" o "issuewild", una CA può interpretarlo come un autorizzazione per emettere il certificato SSL/TLS per tale dominio. Consulta Scheda 219: Chiarire la gestione dei set di record CAA senza tag proprietà "emissione"/"issuewild".

Per ulteriori informazioni sul processo di controllo CAA RR, consulta la nostra pagina Controllo dei record risorsa DNS CAA.

Aprile 1, 2018

compliance

Come parte del trasferimento a livello di settore da TLS 1.0/1.1 e per mantenere la nostra compliance PCI, DigiCert ha disabilitato TLS 1.0/1.1 il 1° aprile 2018. D’ora in avanti DigiCert supporta solo TLS 1.2 e versioni successive. Consulta Deprecazione di TLS 1.0 e 1.1.

Marzo 2, 2018

compliance

DigiCert implementa un processo di verifica dell’unità organizzativa (OU) migliorato.

Secondo i requisiti base:

"CA SHALL implementa un processo che impedisce a un attributo OU di includere un nome, la data di nascita, il nome commerciale, il marchio, l’indirizzo, la sede o altri testi che si riferiscono ad una persona naturale specifica o ad un’entità legale a meno che la CA non abbia verificato queste informazioni secondo la Sezione 11.2…"

Nota: Il campo OU è un campo facoltativo. Non è obbligatorio includere un’unità organizzazione in una richiesta di certificato.

compliance

A partire dal 1° marzo 2018, 825 giorni corrispondono alla lunghezza consentita massima per un certificato SSL/TLS triennale pubblico riemesso (o duplicato emesso).

Per un certificato OV triennale emesso dopo il 1° marzo 2017, non dimenticare che durante il primo anno della durata del certificato triennale, tutti i certificati riemessi e duplicati possono avere una durata inferiore rispetto al certificato "originale", e che questi certificati riemessi scadranno per primi. Consulta
In che modo ciò interessa le riemissioni del mio certificato triennale e le emissioni dei duplicati?.

Febbraio 21, 2018

compliance

A partire dal 21 febbraio 2018, DigiCert offre solo certificati SSL/TLS pubblici di 1 e 2 anni a causa delle modifiche apportate agli standard di settore che limitano la lunghezza massima di un certificato SSL pubblico a 825 giorni (circa 27 mesi). Consulta 20 febbraio 2018, ultimo giorno per i nuovi ordini di certificato triennali.

compliance

Solo a scopo informativo, non è necessaria alcuna azione.

A partire dal 1° febbraio 2018, DigiCert pubblica tutti i certificati SSL/TLS pubblici appena emessi nei registri CT pubblici. Tale operazione non influisce su alcun certificato OV emesso prima del 1° febbraio 2018. Non dimenticare che la registrazione CT è necessaria per i certificati EV dal 2015. Consulta I certificati DigiCert saranno registrati pubblicamente a partire dal 1° febbraio.

enhancement

Nuova funzione "Escludi dal registro CT quando ordini un certificato" aggiunta a CertCentral. Quando attivi questa funzione (Impostazioni > Preferenze), consenti agli utenti account di impedire che i certificati SSL/TLS pubblici vengano registrati nei registri CT pubblici in base all’ordine dei certificati.

Quando si ordina un certificato SSL, gli utenti hanno la possibilità di non registrare il certificato SSL/TLS nei registri CT pubblici. La funzione è disponibile quando un utente ordina un nuovo certificato, riemette un certificato e rinnova un certificato. Consulta la Guida alla registrazione CT dei certificati SSL/TLS pubblici CertCentral.

enhancement

Nuovo campo per negare la registrazione CT opzionale (disable_ct) aggiunto agli endpoint API della richiesta di certificato SSL. Inoltre, è stata aggiunta il nuovo endpoint per negare la registrazione CT del certificato emesso (ct-stato). Consulta la Guida alla negazione Certificate Transparency SSL/TLS pubblici API CertCentral.

Ottobre 24, 2017

compliance

Modifica ai controlli dei record risorsa CAA in base agli standard di settore. Modificato il processo per controllare le catene CNAME contenenti 8 record CNAME o meno, e la ricerca non include l’elemento principale di un target di un record CNAME. Consulta Controllo dei record risorsa DNS CAA.

Settembre 8, 2017

compliance

Modifica dell’emissione certificato secondo gli standard di settore. Modificato il processo di emissione certificato per controllare i record risorsa DNS CAA. Consulta Controllo dei record risorsa DNS CAA.

Luglio 28, 2017

compliance

Modifiche di conformità agli standard di settore; miglioramento dei controlli delle violazioni e adempimenti RFC 5280. Consulta Certificati attendibili pubblicamente – Dati inseriti che violano gli standard di settore.

Luglio 21, 2017

compliance

Modifica al processo di convalida per gli standard di settore. Le informazioni di convalida (DCV o organizzazione) più vecchie di 825 giorni devono essere riconvalidate prima di elaborare la riemissione, rinnovo o emissione di un certificato. Altri dettagli »

Luglio 10, 2017

compliance

Modifiche di conformità agli standard di settore; supporto aggiunto per altri metodi di convalida del controllo del dominio (DCV). Consulta Preconvalida dominio: Metodi di convalida del controllo del dominio (DCV).