Ramos da InformáticaPHPComo Gerar Certificados Digitais Locais com OpenSSL PHP

Como Gerar Certificados Digitais Locais com OpenSSL PHP

-

Neste artigo você verá um passo a passo sobre como gerar certificados digitais locais com OpenSSL com exemplos em PHP.

Como Gerar Certificados Digitais Locais com OpenSSL PHP

Entender a hierarquia de certificados não é apenas teoria. Para testar integrações modernas em ambiente de desenvolvimento (localhost) — como a receção segura de Webhooks externos ou a configuração de cookies seguros (Secure/HttpOnly) numa API Node.js — você precisa de rodar a sua aplicação em HTTPS. É exatamente para isso que serve a criação de uma Autoridade Certificadora (CA) local.

O que são chaves e tipos de certificados digitais

Chaves públicas e privadas

Existem várias formas de se identificar a origem de um determinado arquivo. Uma dessas formas é através do uso de um “par de chaves”. Uma chave privada e uma chave pública. A chave privada é exclusivamente sua e não deve ser entregue a ninguém. A chave pública deve estar disponível ao público em geral. Os algoritmos que trabalham com este par de chaves, encriptam com a chave privada e descriptam com a chave pública. Desta forma, por a chave privada não ser conhecida, se algum arquivo puder ser descriptografado com a chave pública conhecida de um determinado usuário, temos a certeza que este arquivo veio daquele usuário. Da mesma forma se encriptarmos um arquivo com a chave pública do usuário somente ele poderá descriptar com a chave privada.

LEIA TAMBÉM:

Dica de Leitura: Se você está explorando a integração de tecnologias avançadas como certificados digitais em seus projetos, pode ser interessante também entender como ferramentas de IA como o OpenAI Codex podem ser utilizadas para aumentar a eficiência no desenvolvimento de software. Leia nosso artigo sobre Guia para usar o OpenAI Codex com mais eficiência para descobrir novas possibilidades.

Construindo API com PHP e Orientação a Objetos

10 ideias que todos os desenvolvedores deveriam fazer

Hashes

Outro conceito é a integridade do documento. Garantir que o documento que chega ao destino é exatamente o mesmo da origem. Para isso se calcula o “hash” do arquivo, ou seja, um conjunto de caracteres que representa o arquivo e que tem garantia matemática de ser único para um certo arquivo. O hash do arquivo pode público. Se no destino você compara o hash do seu arquivo com o hash inicial, você assegura a integridade do mesmo. Existem vários algoritmos de hash. Um dos mais comuns é o MD5.

Assinatura digital

De forma simplificada, uma assinatura digital nada mais é que um hash criptografado pela chave privada de um usuário.

Certificados Digitais

O problema é: quem garante que aquela chave é daquele usuário ? resposta: alguém conhecido por todos. Ou seja uma autoridade certificadora pública. Essas entidades cobram por seus serviços. São como cartórios digitais. Existem várias com preços diferenciados. Elas fornecem os chamados “certificados digitais” que contêm o par de chaves que você precisa para assinar coisas, para poder se identificar digitalmente entre outras funções.

Hierarquia de certificados

Assim um certificado para ser válido tem uma “hirarquia de certificados”, ou seja, um outro certificado que valida o seu certificado, outro que valida a entidade que lhe certificou, até chegar à entidade raiz nacional (no nosso caso a ICP-Brasil). Esta hirarquia normalmente tem poucos passos. No máximo uns 4.

Certificados de servidor

Além do próprio usuário ter um certificado para si, para que você possa acessar certificados em um certo servidor, você precisa habilitar o modo HTTPS. Pra isso o próprio servidor precisa de um certificado para garantir que aquela máquina é realmente a máquina que você quer acessar. você então habilita o modo HTTPS no servidor HTTP de sua preferência, usando o certificado de servidor.

Meio físico de armazenamento

Esses certificados podem ser fornecidos de várias formas:

– A1 que são basicamente arquivos que você próprio pode gravar em um pen-drive ou algo assim e importar diretamente no navegador.

– A3 que são dispositivos de hardware especiais para conter apenas certificados. Parecem um pen-drive, mas têm a função especial de conter certificados em uma memória especial. Existem outras versões que vêm em cartões com a mesma função. A vantangem é que por ser hardware específico são mais seguros do que um certificado presente em um único arquivo, que pode ser apagado ou sustituído facilmente. Neste caso além do custo do certificado existe o custo do hardware.

VAI GOSTAR:

Se quiser você pode criar sua própria autoridade certificadora e emitir seus próprios certificados. O problema disto é que você não tem a segurança de transações que garantem todo o processo e pode ser vítima do famigerado ataque “Man-in-the-middle” se alguém conseguir ficar no meio da origem e destino dos seus dados. Ou seja, sua entidade certificadora não é conhecida do público em geral e por isso não pode ser garantida a origem dos seus dados. Normalmente certificadoras desse tipo são usadas apenas para desenvolvimento e os certificados reais são comprados para os servidores de produção.

Para assinar e verificar um arquivo

Então vamos aos passos de forma mais elaborada:

  1. Você precisa obter um certificado digital válido de uma entidade certificadora
  2. Caso seja um certificado A3 carregue o driver do dispositivo na função “dispositivos de segurança no seu navegador”.
  3. Importe os certificados da sua entidade certificadora na aba “autoridades” da função certificados de seu navegador
  4. Importe o seu certificado na aba “pessoas”
  5. Abra o seu certificado e exporte para arquivos a chave pública e privada
  6. Em seu arquivo PHP carregue para uma variável o arquivo PDF e para outra a chave privada
  7. Use a função openssl_sign com essas 2 variáveis para criar a assinatura (cheque a documentação)
  8. Para verificar a assinatura use openssl_verify com a chave pública.

 

Para usar certificados digitais em uma aplicação web

  1. Siga os passos 1 a 4 acima.
  2. Obtenha um certificado digital para o servidor
  3. Configure o seu servidor HTTP para usar aquele certificado e habilitar o modo HTTPS
  4. Com o seu certificado instalado na sua máquina e o servidor configurado para HTTPS, deve ser solicitada a senha do seu certificado ao acessar o site. Este processo de solitação de senha acontece antes de aparecer qualquer página do seu site, pq o protocolo HTTPS é negociado antes da transmissão das páginas HTTP.
  5. Uma vez feito os passos acima, no sistema você poderá acessar o certificado do cliente através de da variável global $_SERVER['SSL_CLIENT_CERT']. você pode converter o conteúdo dessa variável em um array contendo os dados presentes no certificado (dados pessoais) com o comando openssl_x509_parse($_SERVER['SSL_CLIENT_CERT']).
  6. As chaves pública e privada podem ser obtidas com os comandos openssl_get_publickey() e openssl_get_privatekey() respectivamente. Lembre-se que você só pode obter a chave privada de seus próprios certificados. A chave privada é reservada ao dono do certificado.
  7. Depois utilize os passos 6 a 8 do procedimento acima para assinar e verificar um documento.

 

Configurar HTTPS no Apache 2

Coloque em um arquivo (digamos ‘cadeiadecertificados.crt’) toda a hirarquia de certificados do certificado de servidor. É só copiar e colar um embaixo do outro em um arquivo texto mesmo. Deixe o certificado de servidor em um arquivo separado (‘servidor.crt’) e a chave privada do certificado do servidor em outro (‘servidor.key’).

Segue abaixo um modelo de configuração HTTPS no Apache 2

<VirtualHost *:443>
    ServerAdmin webmaster@localhost

    DocumentRoot /var/www
    Alias /sistema /opt/sistema
    <Directory /opt/sistema>
        Options Indexes FollowSymLinks MultiViews 
        AllowOverride All
        AcceptPathInfo On
        Order allow,deny
        allow from all
    </Directory>

    SSLEngine on
    SSLOptions +StdEnvVars +ExportCertData
    SSLCertificateFile      /opt/sistema/certs/servidor.crt
    SSLCertificateKeyFile   /opt/sistema/certs/servidor.key
    SSLCACertificateFile    /opt/sistema/certs/cadeiadecertificados.crt
    SSLVerifyClient require
    SSLVerifyDepth  10

    ErrorLog ${APACHE_LOG_DIR}/error.log
    LogLevel warn
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Criando uma autoridade certificadora local e um certificado de servidor assinado localmente

O script Bash (Linux) abaixo cria uma autoridade certificadora para emissão local de certificados.

  1. certifique-se que o pacote openssl está instalado. Caso não esteja instale com sudo apt-get install openssl (distribuições debian), ou comando correspondente em sua distribuição.
  2. coloque o código abaixo em um arquivo com nome “openssl.cnf” e mantenha este arquivo na mesma pasta dos scripts abaixo.

O arquivo openssl.cnf:

#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#

# This definition stops the following lines choking if HOME isn't
# defined.
HOME            = .
RANDFILE        = $ENV::HOME/.rnd

# Extra OBJECT IDENTIFIER info:
#oid_file       = $ENV::HOME/.oid
oid_section     = new_oids

# To use this configuration file with the "-extfile" option of the
# "openssl x509" utility, name here the section containing the
# X.509v3 extensions to use:
# extensions        = 
# (Alternatively, use a configuration file that has only
# X.509v3 extensions in its main [= default] section.)

[ new_oids ]

# We can add new OIDs in here for use by 'ca', 'req' and 'ts'.
# Add a simple OID like this:
# testoid1=1.2.3.4
# Or use config file substitution like this:
# testoid2=${testoid1}.5.6

# Policies used by the TSA examples.
tsa_policy1 = 1.2.3.4.1
tsa_policy2 = 1.2.3.4.5.6
tsa_policy3 = 1.2.3.4.5.7

####################################################################
[ ca ]
default_ca  = CA_default        # The default ca section

####################################################################
[ CA_default ]

dir     = .         # Where everything is kept
certs       = $dir/certs        # Where the issued certs are kept
crl_dir     = $dir/crl      # Where the issued crl are kept
database    = $dir/index.txt    # database index file.
#unique_subject = no            # Set to 'no' to allow creation of
                    # several ctificates with same subject.
new_certs_dir   = $dir          # default place for new certs.

certificate = $dir/cacert.pem   # The CA certificate
serial      = $dir/serial       # The current serial number
crlnumber   = $dir/crlnumber    # the current crl number
                    # must be commented out to leave a V1 CRL
crl     = $dir/crl.pem      # The current CRL
private_key = $dir/private/cakey.pem# The private key
RANDFILE    = $dir/private/.rand    # private random number file

x509_extensions = usr_cert      # The extentions to add to the cert

# Comment out the following two lines for the "traditional"
# (and highly broken) format.
name_opt    = ca_default        # Subject Name options
cert_opt    = ca_default        # Certificate field options

# Extension copying option: use with caution.
# copy_extensions = copy

# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs
# so this is commented out by default to leave a V1 CRL.
# crlnumber must also be commented out to leave a V1 CRL.
# crl_extensions    = crl_ext

default_days    = 365           # how long to certify for
default_crl_days= 30            # how long before next CRL
default_md  = default       # use public key default MD
preserve    = no            # keep passed DN ordering

# A few difference way of specifying how similar the request should look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that :-)
policy      = policy_match

# For the CA policy
[ policy_match ]
countryName     = match
stateOrProvinceName = match
organizationName    = match
organizationalUnitName  = optional
commonName      = supplied
emailAddress        = optional

# For the 'anything' policy
# At this point in time, you must list all acceptable 'object'
# types.
[ policy_anything ]
countryName     = optional
stateOrProvinceName = optional
localityName        = optional
organizationName    = optional
organizationalUnitName  = optional
commonName      = supplied
emailAddress        = optional

####################################################################
[ req ]
default_bits        = 1024
default_keyfile     = privkey.pem
distinguished_name  = req_distinguished_name
attributes      = req_attributes
x509_extensions = v3_ca # The extentions to add to the self signed cert

# Passwords for private keys if not present they will be prompted for
# input_password = secret
# output_password = secret

# This sets a mask for permitted string types. There are several options. 
# default: PrintableString, T61String, BMPString.
# pkix   : PrintableString, BMPString (PKIX recommendation before 2004)
# utf8only: only UTF8Strings (PKIX recommendation after 2004).
# nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings).
# MASK:XXXX a literal mask value.
# WARNING: ancient versions of Netscape crash on BMPStrings or UTF8Strings.
string_mask = utf8only

# req_extensions = v3_req # The extensions to add to a certificate request

[ req_distinguished_name ]
countryName         = Country Name (2 letter code)
countryName_default     = AU
countryName_min         = 2
countryName_max         = 2

stateOrProvinceName     = State or Province Name (full name)
stateOrProvinceName_default = Some-State

localityName            = Locality Name (eg, city)

0.organizationName      = Organization Name (eg, company)
0.organizationName_default  = Internet Widgits Pty Ltd

# we can do this but it is not needed normally :-)
#1.organizationName     = Second Organization Name (eg, company)
#1.organizationName_default = World Wide Web Pty Ltd

organizationalUnitName      = Organizational Unit Name (eg, section)
#organizationalUnitName_default =

commonName          = Common Name (e.g. server FQDN or YOUR name)
commonName_max          = 64

emailAddress            = Email Address
emailAddress_max        = 64

# SET-ex3           = SET extension number 3

[ req_attributes ]
challengePassword       = A challenge password
challengePassword_min       = 4
challengePassword_max       = 20

unstructuredName        = An optional company name

[ usr_cert ]

# These extensions are added when 'ca' signs a request.

# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.

basicConstraints=CA:FALSE

# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.

# This is OK for an SSL server.
# nsCertType            = server

# For an object signing certificate this would be used.
# nsCertType = objsign

# For normal client use this is typical
# nsCertType = client, email

# and for everything including object signing:
# nsCertType = client, email, objsign

# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment

# This will be displayed in Netscape's comment listbox.
nsComment           = "OpenSSL Generated Certificate"

# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer

# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren't
# deprecated according to PKIX.
# subjectAltName=email:move

# Copy subject details
# issuerAltName=issuer:copy

#nsCaRevocationUrl      = http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName

# This is required for TSA certificates.
# extendedKeyUsage = critical,timeStamping

[ v3_req ]

# Extensions to add to a certificate request

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment

[ v3_ca ]


# Extensions for a typical CA


# PKIX recommendation.

subjectKeyIdentifier=hash

authorityKeyIdentifier=keyid:always,issuer

# This is what PKIX recommends but some broken software chokes on critical
# extensions.
#basicConstraints = critical,CA:true
# So we do this instead.
basicConstraints = CA:true

# Key usage: this is typical for a CA certificate. However since it will
# prevent it being used as an test self-signed certificate it is best
# left out by default.
# keyUsage = cRLSign, keyCertSign

# Some might want this also
# nsCertType = sslCA, emailCA

# Include email address in subject alt name: another PKIX recommendation
# subjectAltName=email:copy
# Copy issuer details
# issuerAltName=issuer:copy

# DER hex encoding of an extension: beware experts only!
# obj=DER:02:03
# Where 'obj' is a standard or added object
# You can even override a supported extension:
# basicConstraints= critical, DER:30:03:01:01:FF

[ crl_ext ]

# CRL extensions.
# Only issuerAltName and authorityKeyIdentifier make any sense in a CRL.

# issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always

[ proxy_cert_ext ]
# These extensions should be added when creating a proxy certificate

# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.

basicConstraints=CA:FALSE

# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.

# This is OK for an SSL server.
# nsCertType            = server

# For an object signing certificate this would be used.
# nsCertType = objsign

# For normal client use this is typical
# nsCertType = client, email

# and for everything including object signing:
# nsCertType = client, email, objsign

# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment

# This will be displayed in Netscape's comment listbox.
nsComment           = "OpenSSL Generated Certificate"

# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer

# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren't
# deprecated according to PKIX.
# subjectAltName=email:move

# Copy subject details
# issuerAltName=issuer:copy

#nsCaRevocationUrl      = http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName

# This really needs to be in place for it to be a proxy certificate.
proxyCertInfo=critical,language:id-ppl-anyLanguage,pathlen:3,policy:foo

####################################################################
[ tsa ]

default_tsa = tsa_config1   # the default TSA section

[ tsa_config1 ]

# These are used by the TSA reply generation only.
dir     = ./demoCA      # TSA root directory
serial      = $dir/tsaserial    # The current serial number (mandatory)
crypto_device   = builtin       # OpenSSL engine to use for signing
signer_cert = $dir/tsacert.pem  # The TSA signing certificate
                    # (optional)
certs       = $dir/cacert.pem   # Certificate chain to include in reply
                    # (optional)
signer_key  = $dir/private/tsakey.pem # The TSA private key (optional)

default_policy  = tsa_policy1       # Policy if request did not specify it
                    # (optional)
other_policies  = tsa_policy2, tsa_policy3  # acceptable policies (optional)
digests     = md5, sha1     # Acceptable message digests (mandatory)
accuracy    = secs:1, millisecs:500, microsecs:100  # (optional)
clock_precision_digits  = 0 # number of digits after dot. (optional)
ordering        = yes   # Is ordering defined for timestamps?
                # (optional, default: no)
tsa_name        = yes   # Must the TSA name be included in the reply?
                # (optional, default: no)
ess_cert_id_chain   = no    # Must the ESS cert id chain be included?
                # (optional, default: no)

Apenas coloque o arquivo openssl.cnf e o script abaixo em uma pasta e rode o script.

#/bin/bash

# Este script cria uma autoridade certificadora (CA) local para ser usada 
# em ambientes desenvolvimento e servir como base para emissão de 
# certificados digitais e um certificado de servidor emitido por esta CA. 
#
# São criados os seguintes arquivos:
# rootCA.key => Chave privada da autoridade certificadora local
# rootCA.crt => Certificado da autoridade certificadora local auto-assinado
# server.csr => Solicitação de emissão de certificado de servidor 
# server.key => Chave privada do certificado de servidor solicitado
# server.crt => Certificado de servidor emitido pela autoridade certificadora local
# index.txt e serial são arquivos necessários apenas ao processo de 
# emissão de certificados pelo openssl e não são relevantes para o 
# usuário. Não devem ser apagados mas podem ser ignorados.

echo 00 > serial
touch index.txt

echo "Criar chave privada da Autoridade Ceritficadora (CA)"
openssl genrsa -des3 -passout pass:123 -out  ./rootCA.key 2048

echo "Remover a senha da chave privada"
openssl rsa -passin pass:123 -in ./rootCA.key -out ./rootCA.key

echo "Criar certificado auto-assinado da CA"
openssl req -config openssl.cnf -new -x509 -subj '/C=BR/L=Dev/O=COMPANHIA/CN=CA' -days 99999 -key ./rootCA.key -out ./rootCA.crt

echo "Criar chave privada do servidor"
openssl genrsa -des3 -passout pass:123 -out ./server.key 2048

echo "Remover senha da chave privada do servidor"
openssl rsa -passin pass:123 -in ./server.key -out ./server.key

echo "Criar requisição de certificado para o servidor"
openssl req -config ./openssl.cnf -new -subj '/C=BR/L=Dev/O=COMPANHIA/CN=server' -key ./server.key -out ./server.csr

echo "Criar certificado para o servidor a partir da requisição de certificado"
openssl ca -batch -config ./openssl.cnf -days 999 -in ./server.csr -out ./server.crt -keyfile ./rootCA.key -cert ./rootCA.crt -policy policy_anything

echo "Apagando arquivos temporários"
rm -f index.txt*
touch index.txt
rm serial.old
rm *.pem

echo "Finalizado."

Emitindo certificados a partir da autoridade certificadora local

O script abaixo emite certificados a partir da autoridade certificadora criada com o script acima.

#!/bin/bash

# Este script emite certificados com base na autoridade certificadora 
# local. É criada uma pasta cujo nome é o nome do dono do certificado, 
# contendo os seguintes arquivos:
# <NOME>.key => Chave privada do usuário
# <NOME>.csr => Requisição de certificado à CA local
# <NOME>.crt => Certificado emitido pela CA local
# <NOME>.p12 => Certificado em formato PKCS12

if [[ -z "$1" || -z "$2" ]]; then
    echo "Uso: emitircertificado <NOME> <CPF>"
    exit
fi

NOME=$1
CPF=$2
DN="/C=BR/L=Dev/O=COMPANHIA/CN=$1:$2"
ARQ="${NOME//[[:space:]]/}"

echo -e "\nCriando pasta... " 
mkdir $ARQ
echo "feito."

echo -e "\nCriando chave privada... "
openssl genrsa -des3 -passout pass:123 -out ./$ARQ/$ARQ.key 2048
echo "feito."

echo -e "\nRemovendo senha..."
openssl rsa -passin pass:123 -in ./$ARQ/$ARQ.key -out ./$ARQ/$ARQ.key
echo "feito."

echo -e "\nCriando CSR... "
openssl req -config ./openssl.cnf -new -subj "$DN" -key ./$ARQ/$ARQ.key -out ./$ARQ/$ARQ.csr
echo "feito."

Leia também:

FAQ: Certificados Digitais no Desenvolvimento

1. Por que preciso gerar um certificado SSL local no meu ambiente de desenvolvimento?
+

Desenvolver apenas em HTTP localmente cria um falso senso de segurança. Muitas APIs modernas de pagamento, ferramentas de inspeção de Webhooks e políticas estritas de cookies (como SameSite=None) exigem um contexto seguro (HTTPS) para funcionar. Gerar uma CA local permite simular perfeitamente o ambiente de produção na sua própria máquina.

2. Qual a diferença prática entre um certificado A1 e A3 na programação?
+

O Certificado A1 é emitido via software (um ficheiro .pfx ou .p12 com validade de 1 ano) e pode ser facilmente automatizado em pipelines de CI/CD ou servidores web. O Certificado A3 é armazenado em hardware (Token USB ou Smartcard, válido por 3 anos); oferece maior segurança física, mas é extremamente complexo de integrar em rotinas de automação de servidores (backend).

3. Posso usar os certificados gerados por este script OpenSSL em produção?
+

Não. O script fornecido cria uma CA autoassinada (Self-Signed). Os navegadores dos seus utilizadores finais não reconhecerão a sua máquina como uma Autoridade de Confiança e exibirão um alerta de segurança vermelho (“A sua ligação não é privada”). Para produção, utilize certificados emitidos por autoridades reais, como a Let’s Encrypt (gratuita) ou a ICP-Brasil.

Ramos da Informática
Ramos da Informáticahttps://ramosdainformatica.com.br
Ramos da Informática é um hub de comunidade dedicado a linguagens de programação, banco de dados, DevOps, Internet das Coisas (IoT), tecnologias da Indústria 4.0, cibersegurança e startups. Com curadoria de conteúdos de qualidade, o projeto é mantido por Ramos de Souza Janones.

Mais recentes

Como aprender a programar, um guia definitivo

Última atualização em 23/04/2026. Guia completo sobre: Como aprender a programar. Espero que este “guia” ou “manifesto”, como prefiro chamar, seja...

Stream Deck para Desenvolvedores: o Console de Comando do Futuro

Esqueça os streamers. Descubra como o Stream Deck se tornou o hardware essencial para Engenheiros de IA e Full...

Como Usar o Skills in Chrome no Brasil: Tutorial Completo de IA

A inteligência artificial já faz parte do nosso fluxo de trabalho, mas ter que reescrever os mesmos prompts repetidamente...

Context Engineering: Como Arquitetar Dados para LLMs e RAG

Na edição desta newsletter intitulada “Engenharia de Prompt: Não é só mais uma buzzword“: https://www.linkedin.com/pulse/engenharia-de-prompt-n%C3%A3o-%C3%A9-s%C3%B3-mais-uma-buzzword-de-souza-janones-tpkxf tratei sobre o tema...
E-Zine Dev

Evolua para Sênior

Estratégias de Node.js, arquitetura Limpa e IA que nunca publicamos no blog. Junte-se a +10.000 devs.

Assinar Gratuitamente Zero spam. Cancele quando quiser.

Aprender Idiomas com Google Tradutor: Na Prática

O Google está lançando um novo recurso experimental com tecnologia de IA no Google Tradutor, projetado para ajudar as...

Comunidades Internacionais de Desenvolvedores

Descubra as melhores comunidades internacionais de devs para 2026: GitHub, Stack Overflow, Discord e mais. Comparativo de salários Brasil vs. exterior e guia de carreira remota.

Mais Lidos

Como Retornar o Último Registro de Cada Grupo no SQL

Recuperar o último registro de cada grupo em um...

n8n vs Zapier em 2026: Qual a Melhor Plataforma de Automação e IA

Conheça sobre o n8n gere integrações e automações para...

Guia de Engenharia de Prompt: O Papel da Engenharia de Prompt

Quando surgiu o tema “Engenharia de Prompt”, logo pensei:...

PostgreSQL Tuning: Como Otimizar a Performance

Melhore a performance do seu PostgreSQL. Aprenda a configurar...
E-Zine Dev

Evolua para Sênior

Estratégias de Node.js, arquitetura Limpa e IA que nunca publicamos no blog. Junte-se a +10.000 devs.

Assinar Gratuitamente Zero spam. Cancele quando quiser.

Você vai gostarrelacionados
Continue aprendendo

E-Zine Dev Ramos

Quer dominar arquitetura e IA?

Junte-se a +10.000 profissionais. Receba semanalmente estratégias de Node.js, React e IA que nunca publicamos no blog.

Assinar Gratuitamente Zero spam. Cancele quando quiser.