יישמנו מודול ES עבור חברת לוגיסטיקה עם זרימת מסמכים חודשית של 20,000 מסמכים. הם איבדו 3 ימים על כל חוזה. לאחר שילוב CAdES-X Long Type 1 עם CryptoPro CSP לחתימות אלקטרוניות, הזמן ירד לשעתיים, וחיסכון בעלויות השליחים הסתכם ב-$1.4k–1.9k לחודש. התוקף המשפטי של החתימה מוסדר על ידי החוק הפדרלי מס' 63-FZ "על חתימות אלקטרוניות." אנו מפתחים מודולים כאלה עבור 1C-Bitrix, ומטמיעים את הערימה הקריפטוגרפית ישירות בזרימת המסמכים שלך. עם ניסיון של למעלה מ-10 שנים — השלמנו יותר מ-30 פרויקטים. קבלו ייעוץ — נעריך לוחות זמנים והיקף באופן אישי. עלות פיתוח המודול מחושבת באופן אישי בהתאם לפורמט ומורכבות האינטגרציה.
הבטחת תוקף משפטי של החתימה
חתימות אלקטרוניות ברוסיה מוסדרות על ידי 63-FZ. לתוקף משפטי, נדרשת חתימה מוסמכת (QES) עם תעודה מ-CA מוסמך. המודול שלנו משתמש ב-CryptoPro CSP, המוסמך על ידי ה-FSB של רוסיה. חתימת CAdES-X Long Type 1 כוללת חותמת זמן ותגובות OCSP, המאפשרות אימות גם לאחר 10 שנים. אנו מבטיחים שהמודול עובד כראוי עם כל CA מהרישום של משרד הפיתוח הדיגיטלי. במידת הצורך, אנו מגדירים את שרשרת האמון באמצעות תעודות שורש.
ערימה קריפטוגרפית: CryptoPro CSP ופורמטי חתימה
התקן דה-פקטו עבור ES רוסי הוא CryptoPro CSP. ביישומי אינטרנט, השילוב הבא עובד:
- CryptoPro CSP — ספק קריפטוגרפי על מחשב המשתמש (או השרת). מיישם GOST R 34.10-2012 ו-GOST R 34.11-2012
- CryptoPro Browser Plugin — יישום מקורי + הרחבה עבור Chrome/Firefox/Edge
- cadesplugin.js — ספריית JavaScript לעבודה עם התוסף דרך
cadesplugin.CreateObjectAsync()
פורמטי חתימה שמופיעים בפועל בפרויקטים:
| פורמט | מה יש בפנים | מתי משתמשים |
|---|---|---|
| CAdES-BES | חתימה + תעודה + שרשרת | זרימת מסמכים פנימית ללא חותמת זמן |
| CAdES-T | CAdES-BES + חותמת זמן | קביעת רגע החתימה |
| CAdES-X Long Type 1 | CAdES-T + תגובות OCSP + CRL | החלפה בעלת משמעות משפטית ואחסון לטווח ארוך (עד 10 שנים) |
בפועל: CAdES-BES לתהליכים פנימיים, CAdES-X Long Type 1 למסמכים שיוצאים מהפרימטר. בחירת הפורמט משפיעה על התשתית — CAdES-X Long Type 1 דורש שרת TSP ומגיב OCSP. CAdES-X Long Type 1 מבטיח אימות חתימה פי 10 יותר מאשר CAdES-BES (עד 10 שנים לעומת 1-2 שנים ללא חתימה מחדש). ניתן לקרוא עוד על התקן ב-ויקיפדיה.
תהליך החתימה: מלחיצה על הכפתור ועד לשרת
זהו הבלוק הטכני המרכזי. בואו נפרק אותו שכבה אחר שכבה — כל שלב מכיל מלכודות.
שלב 1: אתחול התוסף. cadesplugin.js נטען. הספרייה מזהה את הדפדפן ואת שיטת האינטראקציה. האתחול הוא אסינכרוני:
cadesplugin.then(function() { // плагин готов к работе
}, function(error) { // плагин не установлен или расширение отключено
});קריטי: אם התוסף לא מותקן, המשתמש חייב לראות הוראות עם קישורי הורדה. ב-30% מהמקרים, הבעיה היא בדיוק כאן: התוסף מותקן, אבל ההרחבה מושבתת לאחר עדכון Chrome.
שלב 2: בחירת תעודה. ממשק ה-API של התוסף שואל את המאגר. המשתמש רואה רשימה עם שמות ותקופות תוקף. סינון לפי מטרת OID (1.3.6.1.5.5.7.3.4 — חתימת מסמכים) מצמצם את הרשימה. עבור כל תעודה, אנו בודקים:
- תקופת תוקף
- נוכחות מפתח פרטי (אם על טוקן שלא הוכנס, מחזיר
cadesplugin.then(function() { // плагин готов к работе }, function(error) { // плагин не установлен или расширение отключено });) - סטטוס ביטול ראשוני באמצעות CRL במטמון
שלב 3: יצירת חתימה. המסמך מועבר כמחרוזת Base64. תהליך עבור CAdES-BES:
- צור אובייקט CAdESCOM.CadesSignedData
- הגדר את התוכן
- קרא ל-SignCades() עם התעודה וסוג החתימה
- תוצאה: מחרוזת CMS ב-Base64 (חתימה מנותקת)
כאשר קוראים ל-SignCades(), המערכת מבקשת את ה-PIN של הטוקן — זהו דיאלוג מערכת ואינו ניתן להתאמה אישית.
שלב 4: שליחה ושמירה. החתימה נשלחת לשרת באמצעות בקשת AJAX. אנו שומרים:
- מסמך מקורי
- קובץ חתימה (.sig/.p7s)
- מטא-דאטה: נושא התעודה, מספר סידורי, תאריך
עבור CAdES-X Long Type 1, התוסף עצמו יוצר קשר עם TSP ו-OCSP — אבל הם חייבים להיות נגישים. בסביבת ייצור, אתה צריך TSP משלך או מנוי מסחרי.
שגיאות נפוצות ופתרונות
- התוסף מותקן, ההרחבה מושבתת — ה-promise נדחה ללא הודעה ברורה. פתרון: הוסף הוראות כיצד להפעיל את ההרחבה.
- התעודה קיימת, הטוקן לא מחובר — HasPrivateKey() מחזיר false. פתרון: בדוק נוכחות טוקן לפני החתימה.
- שרת TSP לא זמין — CAdES-X Long Type 1 נכשל. פתרון: נפילה ל-CAdES-BES עם אזהרה.
- תעודת CA לבדיקה — הכל עובד בבדיקה, אבל האימות נכשל בייצור. פתרון: הגדר אימות שרשרת אמון.
אימות חתימה בצד השרת
האימות מתבצע באמצעות CryptoPro CSP (מותקן על השרת). עבור PHP — הרחבת phpcades או קריאה ל-cryptcp דרך exec().
אנו מאמתים:
- שלמות: גיבוב המסמך תואם לגיבוב בחתימה
- תוקף התעודה: לא פגה, לא בוטלה
- שרשרת אמון: מהחותם ועד ל-CA השורשי
בדיקת ביטול — שני נתיבים:
- CRL: רשימה שמורדת מעת לעת. עד 24 שעות עיכוב
- OCSP: שאילתה בזמן אמת. OCSP מדויק פי 2 מכיוון שהוא נותן את הסטטוס הנוכחי.
התוצאה נכתבת לשדה VERIFICATION_STATUS. אימות חוזר נעשה על ידי סוכן מתוזמן.
למה אחסון חתימה לטווח ארוך חשוב
הנתונים מאוחסנים בבלוק HL או בטבלה נפרדת:
| שדה | מטרה |
|---|---|
| DOCUMENT_ID | קישור לישות (הזמנה, חוזה, חשבונית) |
| FILE_ID | מקור ב-b_file |
| SIGNATURE_FILE_ID | קובץ חתימה |
| SIGNER_SUBJECT | נתונים מהתעודה |
| SIGN_DATE | תאריך חתימה |
| SIGN_FORMAT | CAdES-BES / CAdES-X Long Type 1 |
| VERIFICATION_STATUS | תוצאת אימות |
| VERIFICATION_DATE | תאריך אימות אחרון |
אחסון לטווח ארוך. אם מסמך מאוחסן במשך 5–10 שנים, אלגוריתמי GOST עשויים להתיישן, והתעודה עשויה לפקוע. פתרון: חתימה חוזרת תקופתית — הוספת חותמת זמן חדשה. סוכן רץ פעם בחודש כדי לבדוק אם חותמת הזמן עומדת לפקוע בתוך 6 החודשים הקרובים ומוסיף חדשה. ללא זה, לאחר 3–5 שנים, חתימת CAdES-X Long Type 1 הופכת לבלתי ניתנת לאימות.
מה כלול בעבודה
- ניתוח דרישות ותשתית (זמינות CryptoPro, סוגי תעודות, פורמטי חתימה)
- פיתוח מודול: צד לקוח (cadesplugin) + צד שרת (אימות, אחסון)
- אינטגרציה עם ישויות Bitrix נדרשות (הזמנות, חשבוניות, חוזים)
- הגדרת בדיקות CRL/OCSP וסוכן החתימה החוזרת
- תיעוד API והוראות משתמש
- הדרכת מנהלים ומפעילים
- 6 חודשי תמיכה טכנית לאחר ההשקה
מודול זה הוא רכיב תשתיתי. המורכבות שלו אינה בנפח הקוד אלא במספר התלויות החיצוניות: ספק קריפטוגרפי, תוסף, TSP, OCSP, תעודות שורש. כל אלמנט דורש הגדרה וניטור. לוחות זמנים לפיתוח — משבועיים עד חודשיים, בהתאם לפורמט ומספר האינטגרציות. העלות מחושבת באופן אישי לאחר ניתוח. הזמינו ייעוץ — נשלח הצעה מסחרית עם מחיר מדויק ולוח זמנים.