Que hay de los saltos de linea al leer los archivos .cer

[Celestino]

buenos dias a todos, tengo una duda acerca del certificado .cer con respecto al validar un xml, esto correcponde asi:
hace un mes un cliente se le emitiron sus facturas el xml y el pdf se le envian por correo electronico, asi mismo el cliente contrata un servicio de validacion para cfd's, el proveedor le devuelve un correo notificando que: "El contenido del certificado es inválido debido a que es diferente al contenido del certificado que se encuentra en el Sitio del SAT, esto puede ser causa de invalidez en el sello."

Pero, ahora esta el pero, sin encambio el resultado que presenta el proveedor es correcto la estructura, el contenido y solo con una alerta la antes mencionada con respecto al certificado.

Para esto solo comento que ese mismo archivo xml ya lo valide con la aplicacion ValidaCFD y esta correcto "No se encontro ningun errror" con el que esta en el sitio del sat no confio a todo dice que esta bien, ahora yo comento; cuando hago la lectura del archivo cer y estraigo en formato base 64 y se asigna al xml lo establece en un orden de salto de linea cada 64 caracteres uso los componentes de chilkat, estoy viendo que el salto de linea es este caracter
en otros xml he encontrado el salto de linea con el caracter


Mi pregunta es, debo decirle al cliente que el xml esta correcto el certificado que esta incluido en el xml debido a que para su mayor compresion de lectura de archivos xml sea mas facil de leerlos o mas bien como siempres nos tuercen es ir recortando en una sola linea, cada cliente quiere su xml persoanlizado.
Que es lo mas correcto
gracias

[RickAlanis]

Debe estar correcto. Considera lo siguiente:

a) El contenido del certificado en el XML no es obligatorio
b) La serie del certificado, por el contrario, sí lo es. Por lo tanto, el certificado lo puedes bajar directamente del sitio del SAT y con él validar el sello.
c) Originalmente, el formato Base64 puede o no contener saltos de línea (linefeed, ASCII 10 o A, en hexadecimal) o retornos de carro (carriage return, ASCII 13 o D, en hexadecimal). Originalmente, el formato Base64 se hizo para incluir archivos con bytes de 8 bits en los correos, que soportan sólo 7 bits por byte y, para que el formato fuera más legible, cada x caracteres (64, 72 u otra cantidad de caracteres) agregaban un salto de línea o un retorno de caro.
d) Cuando conviertes a Base64 un certificado, se le agregan esos saltos de línea o returns y la práctica común es quitarlos para agregar el certificado en el XML.
d) Hay validadores que verifican que el certificado no contenga saltos de línea o returns porque al procesar de "reversa" y obtener el .cer no les crea bien el certificado.

Es mejor pedirle al proveedor que corrija su XML, ya sea eliminando el certificado o colocándolo SIN los
saltos de línea a retornos de carro, pero, si ValidaCFD te dice que es válido, es que lo es.

Si, además, es un CFDi, puedes validar que el SAT ya lo tenga registrado (se puede tardar 2 o más días en aparecer en el portal del SAT, ten paciencia).

[Celestino]

Muchas gracias por los comentarios,
solo por añadir si alguien le sirve, es que independientemente de los objetos o componentes de terceros que usemos para extraer los datos del archivo cer, debemos aplicar un remplace de caracteres tanto de salto de linea como retorno de carro, en mi caso que aun tengo la aplicacion en vb para los cfd version 2.2 use esta funcion Replace(cad_certificado, Chr(13) + Chr(10), "") y volvi a generar el xml y ya no aparecen los caracteres de
otra vez volvi a validar el xml que genere ya sin salto de linea y ret. de carro y esta correcto.

Ahora me falta para las aplicaciones de .net que tengo un desarrollo con el esquema de la version 3.2

y no es lo mismo Chr(13) + Chr(10) que Chr(10) + Chr(13) al hacer un remplace en una cadena

Gracias

[RickAlanis]

Reemplaza de manera independiente cada carácter. ASCII 13 por nulo y luego ASCII 10 por nulo. Así no te equivocas.

Saludos.