eCoC İçin Elektronik İmza, Mühür ve Bulut İmzalama

eCoC İçin Elektronik İmza, Mühür ve Bulut İmzalama

eCoC imzalama hizmeti seçimi, imzalayanın kimliği ve alıcı sistemin teknik kabul şartlarıyla başlar. Kişisel elektronik imza, şirket mührü, TLS sertifikası ve API erişim bilgisi farklı amaçlara hizmet eder.

KategorieCoC Yayınlandı Okuma süresi3 dk Güncellendi
Bu Yazıda Neler Bulacaksınız?
  • eCoC imzalama hizmeti seçimi, imzalayanın kimliği ve alıcı sistemin teknik kabul şartlarıyla başlar. Kişisel elektronik imza, şirket mührü, TLS sertifikası ve API erişim bilgisi farklı amaçlara hizmet eder.
  • Elektronik imza ile elektronik mühür arasındaki fark nedir?
  • Bütün gönderim yollarında aynı imza şartı mı geçerli?
  • Bulut imzalama nasıl değerlendirilmeli?
  • İmzadan sonra ne değişmemeli?

Temel soru “Bu hizmet XML imzalayabilir mi?” ile sınırlı değildir: son IVI dosyanız doğru kimlikle imzalanıp hedef sistem tarafından kabul edilebiliyor mu? Sertifika satın almadan önce belge kimliği, teknik imza profili ve alıcı kabulü arasındaki ilişkiyi doğrulayın.

Kaynak kontrol tarihi: 16 Ekim 2026. Seçim ve test adımları mühendislik önerisidir. Gereken imza seviyesi ve profili seçilen NAP veya makamla teyit edilmelidir.

Elektronik imza ile elektronik mühür arasındaki fark nedir?

Kişisel elektronik imza gerçek kişiyle; şirket elektronik mührü tüzel kişiyle ilişkili verinin kaynağı ve bütünlüğüyle ilgilidir. Avrupa Komisyonunun elektronik mühür açıklaması bu ayrımı ortaya koyar. Terimleri aynı ürünün farklı adları gibi kullanmayın.

Sertifikanın güven seviyesini teknik imza biçiminden de ayırın. Nitelikli sertifika, imza oluşturma cihazı/hizmeti, belge üzerindeki imza ve doğrulama sonucu bağlantılıdır; biri diğerlerinin tamamını kanıtlamaz. Tedarikçinin ürün etiketini teknik şartname yerine koymayın.

Tabloyu yatay kaydırarak tüm sütunları görebilirsiniz.

eCoC projesinde ayrılması gereken kimlik ve kanıtlar
ÖğeAmaçYanıtlanacak soru
Kişisel imza veya kurumsal mühürBelge kimliği ve bütünlüğüAlıcı hangi kimlik ve güven seviyesini kabul ediyor?
XML imza profiliİmzanın dosyaya bağlanma biçimiAlgoritma, referans ve paketleme şartı nedir?
TLS/taşıma sertifikasıGüvenli bağlantıKarşılıklı kimlik doğrulama gerekiyor mu?
API bilgisi veya hesap yetkisiGönderim hizmetini kullanma yetkisiHangi üretici, ortam ve işlemler kapsanıyor?
Alıcı sistem yanıtıHedefteki işlem sonucuİmzalı kayıt gerçekten kabul edildi mi?

Bütün gönderim yollarında aynı imza şartı mı geçerli?

(AB) 2024/1061 güvenli eCoC veri alışverişini ele alır. Uygulanacak hukuk ve hedef sistem şartlarını; kimlik, güven seviyesi, XML profili, sertifika zinciri, doğrulama ve hata yanıtlarını kapsayan yazılı teknik şartlara dönüştürün. Başka bir işlem için alınmış sertifikanın yeterli olduğunu varsaymayın.

VCA güvenlik açıklaması mevcut imza varlığı kontrolünü tarif eder. Bu kontrolü geçmek, bütün kriptografik veya sertifika politikası şartlarının bağımsız doğrulandığı anlamına gelmez. Kendi imza doğrulamanızı ve hedef kabulünü ayrı kaydedin.

Bulut imzalama nasıl değerlendirilmeli?

Bulut hizmeti yerel anahtar yönetimini azaltabilir; ancak işlem sözleşmesi açık olmalıdır. Bazı hizmetler belgeyi, bazıları tanımlanmış özet veriyi alır. Yalnızca hash göndermenin gerekli son XML imzasını üreteceğini varsaymayın. Gönderilen veri, imza oluşturma sorumluluğu ve son dosyanın birleştirilmesi sağlayıcıyla belirlenmelidir.

  1. Kimlik: sertifikanın temsil ettiği tüzel kişi veya yetkili gerçek kişiyi doğrulayın.
  2. İşlem verisi: XML, seçilmiş veri veya özel tanımlı özet gönderildiğini belgeleyin.
  3. Birleştirme: XML imza yapısını ve referanslarını kimin oluşturduğunu belirleyin.
  4. Yetkilendirme: otomatik/toplu işlemlerin nasıl onaylandığını doğrulayın.
  5. Doğrulama: son imzalı çıktı ve sertifika bağlamı için rapor alın.
  6. Süreklilik: kesinti, limit, yenileme ve sertifika değişimini sınayın.

Üretim operatörü imzanın neden başarısız olduğunu özel anahtara erişmeden görebilmelidir. Destek talebinde bütün üretici verisini açmak yerine arındırılmış teknik örnek ve ilgili hata kullanılmalıdır.

İmzadan sonra ne değişmemeli?

Gönderilen dosya, imzanın kapsadığı veri ve yapıyı korumalıdır. XML biçimleme, ad alanı değişiklikleri veya sonradan alan düzenleme doğrulamayı etkileyebilir. Önce içeriği kesinleştirip doğrulayın; sonra imzalayın ve gerçekten gönderilecek son dosyayı kontrol edin.

Dosyanın aynısını eşleştirmek için kriptografik özeti dosyayla birlikte saklayabilirsiniz. Bu; hazırlık, imza, arşiv ve teslim arasında iz sürmeyi kolaylaştırır. Özet, imza doğrulamasının veya makam kabulünün yerine geçmez.

İmzalama hizmeti kabul testi nasıl yapılır?

  • Hedef için şemaya uygun temsili IVI hazırlayın.
  • İnceleme ve imza yetkilendirmesini tamamlayın.
  • Son imza, zincir ve gerekli profili kararlaştırılan yöntemle doğrulayın.
  • Doğru test ortamına gönderip alıcı sonucunu saklayın.
  • Ayrı bir olumsuz testte imzalı değeri değiştirip doğrulamanın yakaladığını gösterin.
  • Sağlayıcı güvenli test imkânı veriyorsa süresi geçmiş veya uygunsuz test sertifikasını sınayın.
  • İmza hizmeti kesildiğinde imzasız üretim kaydı çıkmadan nasıl toparlanıldığını gösterin.

Temsili örnek: 300 araçlık grupta bir kayıt imzadan önce hata alır, diğerinin gönderim yanıtı gelmez. Ekran bu durumları ayırmalıdır. Bütün araçları yeniden imzalamak veya göndermek gereksiz revizyon ve mükerrer kayıt oluşturabilir.

Sertifika yenilemesinin sorumlusu kim?

Kimlik, kullanım amacı, son geçerlilik tarihi, yenileme bağlantısı ve etkilenen entegrasyonları kaydedin. Kurum içi uyarı süresi kimlik kontrolü ve hedef testine zaman bırakmalıdır. Eski sertifika sona ermeden yenisini sınayın; eski kayıtların nasıl imzalandığını açıklayan kanıtı koruyun.

Sözleşme bittiğinde hangi kanıtların dışarı alınabildiğini sorun. Yalnızca portal ekran görüntüsü tutmak, geçmişi açıklamak için üreticiyi hizmet sağlayıcısına bağımlı bırakır.

Sık sorulan sorular

API sertifikası eCoC’yi de imzalar mı?

Varsayılmamalıdır. Bağlantı kimliği ve belge imzası farklı amaçlardır. Sertifikanın kullanım yetkisi ve alıcının belge imza şartı doğrulanmalıdır.

PDF’ye atılan imza IVI XML’i kapsar mı?

Yalnızca PDF üzerindeki imza, ayrı XML’in imzalandığını göstermez. Alıcı hizmetin istediği dosya doğrulanmalıdır.

Her bulut imza hizmeti otomatik seri üretime uygun mu?

Yetkilendirme modeli, otomasyon izni, limitler ve üreticiye ait kimlikle çalışan arayüz ayrıca teyit edilmelidir.

Başarılı testten sonra ne saklanmalı?

Son imzalı dosya, doğrulama raporu, sertifika bağlamı, alıcı yanıtı ve onaylanmış test senaryosu birlikte tutulmalıdır.

Satın almadan önce imza şartlarını belirleyin

Bu listeyi yazılım değerlendirmesiyle birleştirin. Anemon Mühendislik ile NAP veya VCA yolunuzu değerlendirin; üretici iş akışınız için gerekli imza kanıtını tanımlayın.

Özet

İmzalama seçimini doğrulanmış hedef sistem şartları ve tekrarlanabilir kabul testi üzerine kurun. Gönderilen XML, doğrulama kanıtı ve sertifika bilgilerini birlikte saklayın; yenileme ve makam kabulünü ayrı operasyon adımları olarak yönetin.

Homologasyon Blog

Projeniz için uzman desteğine mi ihtiyacınız var?

Homologasyon, tip onayı ve mevzuat süreçlerinde uzman ekibimizle iletişime geçebilirsiniz.