Cómo funciona el protocolo AS2
El RFC 4130 se publicó en julio de 2005 como «Proposed Standard». Su predecesor, AS1 (RFC 3335), transmitía los ficheros por correo electrónico; AS2 traslada el mismo principio a HTTP. Una transmisión sigue estos pasos:
- Su software empaqueta el fichero EDI, por ejemplo una factura EDIFACT, en un mensaje MIME.
- Firma el mensaje con su clave privada y lo cifra con el certificado público del socio (S/MIME, el mismo procedimiento que el del correo electrónico seguro).
- Envía el mensaje por HTTP POST a una dirección del socio acordada previamente, por ejemplo
https://as2.partner.example/as2. - El software del socio descifra, comprueba la firma y devuelve un acuse de recibo, la MDN.
Si la conexión se protege además con TLS (es decir, HTTPS en lugar de HTTP), lo deciden los socios. El fichero en sí está protegido por la firma y el cifrado aunque la conexión no use TLS. Si su socio exige además HTTPS, lo indicará en su guía EDI.
AS2 es un procedimiento punto a punto. No hay intermediario como en una VAN (Value Added Network, red de valor añadido): los ficheros van directamente de servidor a servidor. Encontrará una comparación con otros canales en Canales de transmisión EDI.
AS2-ID y perfil del socio
Cada parte tiene un AS2-ID. Figura en las cabeceras HTTP AS2-From y AS2-To e indica quién envía el mensaje y a
quién va dirigido. Según el RFC 4130, el AS2-ID tiene de 1 a 128 caracteres ASCII imprimibles y distingue entre
mayúsculas y minúsculas. Como valor sirve un número ya existente; el RFC 4130 cita como ejemplo el número DUNS, y
también es posible el GLN. Más información en GLN y otros identificadores.
Un perfil de socio AS2 completo contiene:
| Dato | Ejemplo (ficticio) |
|---|---|
| AS2-ID propio y el del socio | 9520000000011 y PARTNERAS2 |
| Dirección (URL) del socio | https://as2.partner.example/as2 |
| Certificado del socio para el cifrado y la verificación de la firma | fichero partner.cer |
| Algoritmos de firma y cifrado | por ejemplo SHA-256 y AES |
| MDN: firmada o no, síncrona o asíncrona | firmada, síncrona |
| Dirección de pruebas y dirección de producción | a menudo dos URL distintas |
Los valores figuran en la guía EDI de su cliente o en su formulario de alta. Si falta un dato, pregunte en lugar de suponerlo.
Intercambiar certificados
AS2 usa certificados X.509. Según el RFC 4130, los socios pueden usar certificados autofirmados; no es obligatoria una autoridad de certificación. En la práctica, cada parte genera un par de claves y envía a la otra su certificado público, normalmente por correo electrónico o a través de un portal. La clave privada se queda siempre con usted.
Los certificados caducan. Los nuevos deben intercambiarse con tiempo antes de la fecha de caducidad; de lo contrario, fallan la verificación de la firma o el descifrado. Prevea para ello una fecha fija y una supervisión.
La MDN como acuse de recibo, síncrona o asíncrona
La MDN (Message Disposition Notification) es la confirmación de recepción. Si está firmada, contiene un valor de control del mensaje recibido (MIC, Message Integrity Check). Con él puede demostrar que ese fichero exacto llegó sin alteraciones.
En la variante síncrona, la MDN llega como respuesta a la misma llamada HTTP. Es sencillo, porque no hace falta una segunda conexión. Con ficheros muy grandes, sin embargo, la conexión puede agotar el tiempo de espera antes de que el receptor termine.
En la variante asíncrona, el receptor confirma la llamada HTTP de inmediato y envía la MDN más tarde, por una conexión
propia, a una dirección que el emisor indica en la cabecera Receipt-Delivery-Option. Para ello el emisor también
debe ser accesible desde internet.
Errores habituales en las conexiones AS2
- AS2-ID mal escrito: como se distinguen mayúsculas y minúsculas,
Partneras2es un ID distinto dePARTNERAS2. - Certificado incorrecto o caducado: el socio tiene un certificado nuevo y su software sigue usando el antiguo.
- Cortafuegos: la dirección no es accesible desde internet, o el puerto del socio está bloqueado en salida.
- El MIC no coincide: los algoritmos de ambas partes no son los mismos y la MDN se descarta como no válida.
- La MDN asíncrona no llega porque la dirección de retorno es interna o está bloqueada.
- Pruebas y producción intercambiadas: los ficheros de prueba acaban en el sistema real del socio, o al revés.
La mayoría de estos errores se detectan en la primera prueba de conexión. Por eso, antes de cada paso a producción hay una prueba con ficheros de prueba hasta que el fichero y la MDN funcionan sin errores en ambos sentidos.
En qué se diferencia AS4 de AS2
AS4 es un procedimiento más reciente de la organización de normalización OASIS, estándar OASIS desde el 23 de enero de 2013. Según el estándar, nació para aprovechar el éxito de AS2. Frente a AS2, OASIS cita tres novedades: AS4 encaja con los estándares de servicios web (ebMS 3.0, basado en SOAP), los mensajes se pueden recoger («pull») y los acuses de recibo están integrados. Un ámbito de uso importante es Peppol, una red para facturas electrónicas, entre otros documentos: según la especificación de Peppol, el intercambio entre los puntos de acceso (Access Points) se hace por AS4. Qué significa esto para la factura electrónica lo explica EDI, Web-EDI y factura electrónica.
AS2 en edi-service.eu
En edi-service.eu, AS2 forma parte de los canales de transmisión, junto con OFTP2, SFTP, HTTPS y correo electrónico, de entrada y de salida con MDN. El software funciona en su propio servidor; para ello este necesita una dirección fija y un puerto HTTPS de entrada. No ofrecemos acceso propio a Peppol (AS4). Lo que incluye el precio figura en las preguntas frecuentes.
Preguntas frecuentes
¿Qué diferencia hay entre AS2 y SFTP?
AS2 firma y cifra cada fichero y, con la MDN, devuelve un acuse de recibo. SFTP transmite ficheros a través de una conexión SSH cifrada, pero sin acuse de recibo a nivel de negocio. Qué canal usa lo decide normalmente su cliente.
¿Necesito un certificado comprado para AS2?
No necesariamente. El RFC 4130 admite certificados autofirmados. Algunos socios exigen, sin embargo, un certificado de una autoridad de certificación concreta; en ese caso lo indican en su guía EDI.
¿Es mejor una MDN síncrona o asíncrona?
La síncrona es más sencilla y basta con tamaños de fichero normales. La asíncrona compensa con ficheros grandes o procesamientos largos, pero requiere que su sistema también sea accesible desde fuera. Normalmente es el socio quien fija la variante.
¿Está AS2 obsoleto porque existe AS4?
No. El RFC 4130 sigue vigente sin cambios, y AS2 se sigue usando para conexiones directas entre socios comerciales. AS4 lo encontrará sobre todo en redes como Peppol. Qué procedimiento necesita se lo indica la guía EDI de su socio.
¿Tiene la guía AS2 de su cliente y quiere saber si la conexión encaja con edi-service.eu? Enviar una solicitud
Fuentes
- RFC Editor: «RFC 4130: MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)», https://www.rfc-editor.org/rfc/rfc4130 (consultado el 16/10/2026)
- RFC Editor: «RFC 3335: MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet», https://www.rfc-editor.org/rfc/rfc3335 (consultado el 16/10/2026)
- OASIS: «AS4 Profile of ebMS 3.0 Version 1.0», estándar OASIS del 23/01/2013, https://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile/v1.0/os/AS4-profile-v1.0-os.html (consultado el 16/10/2026)
- OpenPeppol: «Peppol AS4 Profile», https://docs.peppol.eu/edelivery/as4/specification/ (consultado el 16/10/2026)