ca認證編寫

『壹』 編程實現創建CA證書····用c語言····

int main()
{
printf("hello,world");
}

『貳』 如何實現Linux中的CA認證

都差不多，rhel是紅帽的認證，lpic是ibm的認證，總體來說費用差不多，國內紅帽用的還是多一些

『叄』 如何通過ca認證實現電子合同的有效性

電子合同要具備法律效力，主要是通過合法CA機構頒發的可信數字證書來對電子合同專進行電屬子簽名。現在國內這樣的電子合同簽名平台很多，魚龍混雜，建議你選擇由CA機構開設的電子簽名平台來進行電子合同簽名，推薦參考WoSignDoc電子簽名平台

『肆』 關於PKI的，如何用PHP編一個CA（認證中心）系統，請高手們指點了 - PHP進階討論

嘿嘿，我也曾經像你一樣迷茫過。不想講那些沒用的大道理，談一下我的看法。
我剛一開始接觸這個就只是對這個感興趣，然後就買了幾本書，剛一開始學的是C,後來又在各大」專業論壇「上聽人說這好又說那好弄的我是一頭霧水。所以我要說的是你沒有必要去關心別人說什麼，也沒有必要說先學什麼後學什麼。
然後對你上面的那個問題做一下回答吧，編寫一個軟體並不困難，但是要看能寫成什麼樣。你說的C語言是你說的這幾個裡面最有歷史的（也是我最喜歡的），他在高級語言裡面最接近底層，同時在底層語言裡面又具有高級語言的特性，所以有人稱它為中級語言。一直到現在他依然被廣泛的使用著，像編譯原理這樣的課程也經常用C來舉例子。然後是php，這東西現在火的很，主要是用來編寫B/S結構的軟體（也就是平時你上的網站，這個也算是軟體），它的開發效率比較高。然後是java，現在基本上也是用來做B/S結構的多一些，當然像Android系統的應用軟體也是採用Java來寫的，Java和PHP相比好處有很多，你去google一下就全知道了，就不解釋了，當然仁者見仁智者見智。嘿嘿。再者我得補充一個C#，當初我就被這東西嚇住了，好多人當時都說「現在誰還用C語言啊，都用.NET了！「後來我差點放棄了C選擇了C#，害人不淺啊。所以咱們不要隨便的說哪個語言取代了哪個語言，因為只有哪個比哪個更合適，而沒有誰比誰更好，就算在哪裡都不合適也可以用來教學嘛，況且C和C#根本就………………
給你的建議就是選一個學，學的時候就別再去關心什麼哪個語言好哪個語言強大了。還有就是你最好能選擇一個好一點的陪訓機構，因為就算你再聰明，在家裡面也很難有學校的那種環境，遇到問題了也更好解決，一個人的自製力是有限的嘛！相信有志者事競成

『伍』 用java怎麼實現CA頒發的數字證書的認證功能

PKI 目前使用最多的非對稱演算法是 RSA。對於基於 RSA 的 PKI 而言，CA 應有一對 RSA 的公私鑰對，私內鑰是 CA 的生命，嚴格容保密，而公鑰則發布給使用方。CA 簽發一張證書的話，主要是使用 CA 的 RSA 私鑰對證書進行簽名，並將簽名結果保存在證書當中。使用者通過 CA 發布的公鑰來驗證證書中的簽名值，就可以確定該證書是否是由該 CA 簽發的。自己要做的就是從證書中提取簽名數據和用於簽名的原始數據，再使用 CA 的公鑰驗證這個簽名就可以了。

『陸』 CA認證登陸怎麼做

方法：

單位用戶抄初次申請數字襲證書時，需攜帶以下材料及相關費用，到數字證書服務網點辦理證書申請。

1、《單位數字證書申請表》紙質申請表一式兩份。

2、《組織機構代碼證》原件及復印件。

3、《社會保險登記證》原件及復印件。

4、《營業執照（副本）》或其他批准成立證照原件及復印件。

5、經辦人有效身份證件原件及復印件。

『柒』 如何用JAVA實現CA認證

by fleshwound (http://www.smatrix.org)
(註：這是我們的完整設計中的一部分，其它有些部分尚要求保密，希望這個拙文能給做J2EE項目的兄弟們帶來點幫助,有任何關於JAVA安全和密碼學理論和應用的問題可以來我們的論壇:http://bbs.smatrix.org)
近年來，隨著互連網和計算機的普及，電子商務和電子政務成為當今社會生活的重要組成部分，以網上訂購和網上在線支付的為主要功能的網店系統(Web Shop System)是目前電子商務的熱門技術。
JAVA以它「一次編譯，處處運行」的神奇魅力和強大的安全技術支持，很快成為WEB信息系統開發的首選語言，而J2EE就是為了WEB應用開發而誕生的。目前J2EE的應用大部份都是多層結構的, 良好的分層可以帶來很多好處，例如可以使得代碼結構清晰，方便組件復用，可以快速適應應用的新需求。同時，JAVA還提供了強大的安全技術(例如:JCA,HTTPS,JSSA等)。對於電子商務系統而言,系統平台的安全性和效率是其中的核心問題,而這些正好是J2EE及其相關技術的強項。

0 系統中所要使用的API及其特點介紹
該系統中主要使用的技術和特點如下:
(1)EJB :主要是作為J2EE中間層，完成商業邏輯。目前主要有三種類型的EJB: 會話 Bean (Session Bean)、實體Bean (Entity Bean)、消息驅動的Bean（MDB）；
(2)JAAS:在J2EE 中用於處理認證和授權服務，進行資源控制；
(3)JSP和Java Servlets:用於J2EE的表示層，生成用戶界面；
(4)JDBC:用於資料庫（資源層）的連接和與資料庫進行交互；
(5)JNDI:Java命名和目錄介面,該API實際上是用來訪問J2EE的所有資源；
(6)JMS:Java消息傳輸服務，配合MDB使用。

1 Session的安全問題與解決方案
在項目中,保存Session一般有兩種方法，一是分別放在客戶端，一是集中放在伺服器端。在客戶端保存Session是指將Session的狀態串列化，然後嵌入到返回給客戶的HTML頁面中。當Session中的信息很少時，這樣實現比較容易，另外這種方法還消除了跨越多個伺服器復制狀態的問題。
但是在客戶端保存Session狀態時，必須考慮到由此帶來的安全問題，因為黑客可能通過嗅探攻擊（Sniffer）獲取敏感信息。為了不讓敏感信息數據暴露，解決的方法是對數據進行加密或者使用HTTPS，採用SSL技術。
如果是要保存大量Session狀態的應用，最好的方法是將Session狀態統一放在伺服器端。當狀態被保存在伺服器上時，不會有客戶端Session管理的大小和類型限制。此外，還避免了由此帶來的安全問題，而且也不會遇到由於在每個請求間傳送Session狀態帶來的性能影響，但是對伺服器的性能要求比較高。網店系統的安全性要求較高，因此Session還是集中放在中間層伺服器端,同時對客戶端到伺服器端採用SSL連接。
2客戶端的緩存安全設計
大部分顧客使用的WEB瀏覽器將瀏覽過的頁面緩存在磁碟上，這樣我們瀏覽網頁的時候不需要重新向伺服器發出HTTP請求，對於普通的網頁不存在安全問題。但是對於需要保密的WEB應用，會帶來安全隱患和泄漏隱私，因此對於客戶端緩存，也必須做適當的處理。最好的方法就是禁止使用緩存，但是對於大部分顧客而言，要求在客戶端不用緩存是不現實的，因此我們必須在中間層解決該問題，方法是採用Servlet過濾器技術。該技術是Servlet2.3以後才出現的，在J2EE中的應用很廣泛。要使用該技術，需要執行以下步驟：
（1） 編寫一個Servlet過濾器，實現javax.servlet.Filter介面；
（2） 修改Web.xml文件，使容器知道過濾器在什麼時候被調用。
Javax.servlet.Filter主要有3個方法：
(1)init(FilterConfig cfg) :當開始使用 servlet 過濾器服務時，容器調用此方法一次。傳送給此方法的 FilterConfig 參數包含 servlet 過濾器的初始化參數；
(2)destroy() :當不再使用 servlet 過濾器服務時，容器調用此方法；
(3)doFilter(ServletRequest req, ServletResponse res, FilterChain chain): 容器為每個映射至此過濾器的 servlet 請求調用此方法，然後才調用該 servlet 本身。傳送至此方法的 FilterChain 參數可用來調用過濾器鏈中的下一個過濾器。當鏈中的最後一個過濾器調用 chain.doFilter() 方法時，將運行最初請求的 servlet。因此，所有過濾器都應該調用 chain.doFilter() 方法。如果過濾器代碼中的附加認證檢查導致故障，則不需要將原始 servlet 實例化。在這種情況下，不需要調用 chain.doFilter() 方法，相反，可將其重定向至其它一些錯誤頁面。
如果 servlet 映射至許多 servlet 過濾器，則按照應用程序的部署描述符（web.xml）中的先後出現的次序來調用 servlet 過濾器。這一部分的主要代碼如下：
//要引入的類庫
import javax.servlet.*;
import javax.servlet.http.HttpServletResponse;
import java.io.*;
import java.security.*;
//設置servlet過濾代碼段
public class CacheFilter implements Filter {
protected FilterConfig filterConfig;
private String cachetp;
//初始化
public void init(FilterConfig filterConfig) throws ServletException
{
this.filterConfig = filterConfig;
cachetp=config.getInitParameter("CacheControlType");
if (cachetp==null)
{
throw new ServletException("沒有定義Cache控制類型");
}
}
//
public void destroy()
{
this.filterConfig = null;
}
//執行過濾器部分
public void doFilter(ServletRequest request,ServletResponse response,FilterChain chain)
throws IOException, ServletException {
if (response instanceof HttpServletResponse )
{
HttpServletResponse resp=(HttpServletResponse) response;
resp.addHeader("Cache-Control",cachetp);
}
else
{
throw new ServletException("非法相應!");
}
chain.doFilter(request, response);
}

}
以下是在Web.xml中添加的對應的內容

CacheFilter
CacheFilter
Cache filter

CacheControlType
no-store

CacheFilter
/cachecontrol

3視圖訪問的安全設置
所有用戶都必須登陸，只有登陸才可以看到用戶的角色和許可權相對應的視圖。因此一個重要的問題就是如何防止一個視圖或者部分的視圖被一個未被授權的客戶直接訪問。
在一些情況下，資源被限制為完全不允許某些用戶訪問,例如：管理後台就不應該讓普通顧客會員訪問。有幾個方法可以做到這一點。一個方法是加入應用邏輯到處理控制器或者視圖的程序中，禁止某些用戶訪問。另一個方案是設置運行時的系統，對於一些資源，僅允許經由另一個應用資源內部調用。在這種情形，對於這些資源的訪問必須被通過另一個表現層的應用資源進行，例如一個servlet控制器。對於這些受限制的資源不允許通過瀏覽器直接調用。
在J2EE中，可以利用Web容器中內置的安全技術來進行角色訪問資源的控制。根據最新版本的servlet和EJB規范，安全限制在web.xml的配置描述文件中描述，我們可以通過配置web.xml來控制角色訪問，修改配置描述文件web.xml就可以達到快速修改安全策略的目的。
安全限制允許使用編程的方法根據用戶的角色來控制訪問。資源可以被某些角色的用戶訪問，同時禁止其它的角色訪問。另外，某個視圖的一部分也可以根據用戶的角色來限制其訪問。如果某些資源完全不允許來自於瀏覽器的直接訪問，那麼這些資源可以配置只允許一些特殊的安全形色訪問，而這些安全形色不分配給任何一個用戶。這樣只要不分配這個安全形色，那麼以這種方式配置的資源將禁止所有的瀏覽器直接訪問。下面一個例子就是web.xml配置文件的一部分，它定義了一個安全的角色以限制直接的瀏覽器訪問。角色的名字是「vip」，受限制資源的名字是specialgood1.jsp、specialgood2.jsp、specialgood3.jsp和bookinfo.jsp。除非一個用戶或者組被分配到「vip」角色，否則這些客戶都不可以直接訪問這些JSP頁面。不過，由於內部的請求並不受這些安全的限制，一個初始時由某servlet控制器處理的請求將會導向到這些受限制的頁面，這樣它們就可以間接訪問這些JSP頁面。
＜security-constraint＞
＜web-resource-collection＞
＜web-resource-name＞specialgood ＜/web-resource-name＞
＜description＞special good infomation＜/description＞
＜url-pattern＞/shop/jsp/a1/specialgood1.jsp＜/url-pattern＞
＜url-pattern＞/shop/jsp/a1/specialgood2.jsp＜/url-pattern＞
＜url-pattern＞/shop/jsp/a1/specialgood3.jsp＜/url-pattern＞
＜url-pattern＞/shop/jsp/a1/bookinfo.jsp＜/url-pattern＞
＜http-method＞GET＜/http-method＞
＜http-method＞POST＜/http-method＞
＜/web-resource-collection＞
＜auth-constraint＞
＜role-name＞vip＜/role-name＞
＜/auth-constraint＞
＜/security-constraint＞
3 各層次間的耦合問題與解決策略
表現層的數據結構，例如HttpServletRequest，應該被限制在表現層上。如果將這些細節放到其它層(主要是業務邏輯層)中，將大大降低了代碼的的重用性，令代碼變得復雜，並且增加了層間的耦合。解決方法一個常用方法是不讓表現層的數據結構和商業層共享，而是拷貝相關的狀態到一個更常見的數據結構中再共享。你也可以選擇由表現層數據結構中將相關的狀態分離出來，作為獨立的參數共享。另外在域對象暴露表現層的數據結構，如果將諸如HttpServletRequest的請求處理數據結構和域對象共享，這樣做也會增加了應用中兩個不同方面的耦合。域對象應該是可重用的組件，如果它們的實現依賴協議或者層相關的細節，它們可重用性就很差，同時維護和調試高耦合的應用更加困難。成熟的解決方案是不通過傳送一個HttpServletRequest對象作為一個參數，而是拷貝request對象的狀態到一個更為常用的數據結構中，並且將這個對象共享給域對象。你也可以選擇由HttpServletRequest對象中將相關的狀態分離出來，並且將每一個的狀態作為一個獨立的參數提供給域對象。
4 EJB的安全設計與控制
EJB的執行過程一般是這樣的：(1)客戶端通過JNDI檢索Home對象的引用；(2)JNDI返回Home對象的引用；(3)請求創建一個新的EJB對象；(4)創建EJB對象；(5)返回EJB對象；(6)調用商務方法；(7)調用Enterprise Bean.引起EJB的安全問題原因主要存在三個方面:
(1)用包嗅探器(Packet Sniffer)獲取用戶憑證信息並直接調用會話Bean；（2）對實體Bean進行未授權訪問；（3）對消息驅動的Bean的無效訪問(發布惡意或者虛假的消息).
以上安全問題可導致客戶端或者服務端欺騙攻擊和DDOS攻擊。解決問題(1)的方法是使用JAVA中SSL技術來保護通訊，解決(2)的方法是對於實體Bean全部採用本地介面或者採用JAAS(文獻[1])，對於(1)和(2)，我們可以同時採取以下措施：讓容器完成認證並傳輸用戶憑證信息,另外使用聲明性或者程序設計的安全驗證角色。對於問題(3),J2EE並沒有提供一個很好的方案，我們的解決方案是採用數字簽名技術來保證信息來自可信任的源。該方法的結合代碼簡要說明如下,消息採用JMS傳遞：
//客戶端，要用到消息發送者的私鑰進行簽名
...
message.setString("userid",userid);
message.setString("useritem",useritem);
message.setInt("usersn",serialnum);//包含一個序列號
message.setString("usercertid",certid);
String signature=getSignature(userid+":"+useritem+":"+serialnum+":"+certid);
//進行簽名,其中getSignature為簽名函數，要用到消息發送者的私鑰進行簽名，具體密碼學技術可參考文獻[2]；
message.setString("signature",signature);
sendmessage(message);//發送信息
...
//伺服器端
String checkstr=userid+":"+message.getString("useritem")+":"+
message.getInt("usersn")+":"+usercertid;
boolean b_check=checkSignature(checkstr,msg.getString("signature"),
usercertid,userid);
//進行驗證,其中checkSignature為驗證函數，要用到消息發送者的公鑰進行驗證，具體密碼學技術可參考文獻[2]；
5 CA中心與證書的生成
前面我們已經提出在客戶端要使用HTTPS和SSL,因此要建立一個自己的CA中心來管理分發證書,加強客戶端到中間層伺服器端通訊的安全性.建立CA中心的第一步是利用JAVA工具包中的Keytool生成一個X509證書,然後將該證書交由權威CA中心Vertsign簽名,再將該證書設置為根證書,建立自己的CA.每次有新用戶注冊交易的時候，都必須簽發一個用戶獨一無二的證書，關鍵的過程是如何簽發證書.簽發證書的過程如下：
(1)從中間層CA伺服器的密鑰庫中讀取CA的證書：
FileInputStream in=new FileInputStream(ShopCAstorename);
KeyStore ks=KeyStore.getInstance("JKS");
ks.load(in,storepass);
java.security.cert.Certificate c1=ks.getCertificate(alias);
(2)獲得CA的私鑰：
PrivateKey caprk=(PrivateKey)ks.getKey(alias,cakeypass);
(3)從CA的證書中提取簽發者信息：
byte[] encod1=c1.getEncoded();
X509CertImpl shopcimp1=new X509CertImpl(encod1);
X509CertInfo shopcinfo1=(X509CertInfo)shopcimp1.get(X509CertImpl.NAME+
"."+X509CertImpl.INFO);
X500Name issuer=(X500Name)shopcinfo1.get(X509CertInfo.SUBJECT+
"."+CertificateIssuerName.DN_NAME);
(4)獲取待簽發的證書相關信息，與（3）類似；
(5)設置新證書的有效期、序列號、簽發者和簽名演算法：
//設置新證書有效期為1年
Date begindate =new Date();
Date enddate =new Date(begindate.getTime()+3000*24*360*60*1000L); CertificateValidity cv=new CertificateValidity(begindate,enddate);
cinfo2.set(X509CertInfo.VALIDITY,cv);
//設置新證書序列號
int sn=(int)(begindate.getTime()/1000);
CertificateSerialNumber csn=new CertificateSerialNumber(sn);
cinfo2.set(X509CertInfo.SERIAL_NUMBER,csn);
//設置新證書簽發者
cinfo2.set(X509CertInfo.ISSUER+"."+
CertificateIssuerName.DN_NAME,issuer);
//設置新證書演算法
AlgorithmId algorithm =
new AlgorithmId(AlgorithmId.md5WithRSAEncryption_oid);
cinfo2.set(CertificateAlgorithmId.NAME+
"."+CertificateAlgorithmId.ALGORITHM, algorithm);
(6)創建證書並簽發：
// 創建證書
X509CertImpl newcert=new X509CertImpl(cinfo2);
// 簽名
newcert.sign(caprk,"MD5WithRSA");
(7)將新證書提供給注冊用戶，並提示安裝,一般的做法是在用戶注冊成功後系統立即返回一個證書對象給中間層某個Servlet，由其返回給用戶。
參考文獻
[1]沈耀,陳昊鵬,李新顏.EJB容器中基於JAAS 的安全機制的實現.[J]:計算機應用與軟體 2004.9 16~18
[2](美)Jess Garms著，龐南等譯. Java安全性編程指南[M].北京:電子工業出版社 2002
[3] http://java.sun.com/j2ee/
[4] 蔡劍,景楠. Java 網路程序設計：J2EE（含1.4最新功能）[M].北京: 清華大學出版社 2003
[5](美)John Bell Tony Loton. Java Servlets 2.3編程指南[M].北京: 電子工業出版社 2002
[6](美)Joseph J.Bambara等著,劉堃等譯. J2EE技術內幕[M].北京:機械工業出版社 2002
[7](美)Li Gong著.JAVA 2平台安全技術——結構、API設計和實現[M].北京: 機械工業出版社 2000
[8](英)Danny Ayers等著,曾國平等譯. Java伺服器高級編程[M].北京：機械工業出版社 2005
[9]http://www.smatrix.org/bbs
[10]http://www.smatrix.cn/bbs

『捌』 如何使用ca證書 實現 電子簽名

《電子簽名法》第13、14條規定：電子簽名同時符合下列條件的，視為可靠的電子簽名：

從技術上來講，可以通過三種方式確保簽署時數字證書由電子簽名人控制：

其一是通過電子簽名人設置簽名密碼;

其二是系統下發驗證碼到電子簽名人提供的手機或郵箱，或提供驗證碼生成器給電子簽名人，通過電子簽名人回填驗證碼的方式確保數字證書由電子簽名人控制;

其三是通過EID調用數字證書。EID是派生於居民身份證、在網上遠程證實身份的證件，即「電子身份證」。在技術上。EID也是採用PKI(Public Key
Infrastructure，公鑰基礎設施)的密鑰對技術，由智能晶元生成私鑰，再由公安部門統一簽發證書、並經現場身份審核後，再發放給公民。EID
採用了PKI、硬證書加PIN碼的技術，通過這些技術可以有效防止在網路上身份信息被截取、篡改和偽造。而且由於EID具有PIN碼，別人撿到或盜取後也
無法使用。EID本身採用先進密碼技術，重要信息在key中物理上就無法被讀取，因此無法被破解，從而有效避免被他人冒用。

如果採用了「數字簽名」技術，一般可認定為可靠的電子簽名。

數字簽名並非是書面簽名的數字圖像化，而是通過密碼技術對電子文檔進行電子形式的簽名。實際上人們可以否認曾對一個文件簽過名，且筆跡鑒定的准確率並非
100%，但卻難以否認一個數字簽名。因為數字簽名的生成需要使用私有密鑰，其對應的公開密鑰則用以驗證簽名，再加上目前已有一些方案，如數字證書，就是把一個實體(法律主體)的身份同一個私有密鑰和公開密鑰對綁定在一起，使得這個主體很難否認數字簽名。

就其實質而言，數字簽名是接收方能夠向第三方證明接收到的消息及發送源的真實性而採取的一種安全措施，其使用可以保證發送方不能否認和偽造信息。

數字簽名的主要方式是：報文的發送方從報文文本中生成一個散列值(或報文摘要)。發送方用自己的私有密鑰對這個散列值進行加密來形成發送方的數字簽名。然後，這個數字簽名將作為報文的附件和報文一起發送給報文的接收方。報文的接收方首先從接收到的原始報文中計算出散列值(或報文摘要)，接著再用發送方的公開密鑰來對報文附加的數字簽名進行解密和驗證。如果兩個散列值(也稱哈希值)相同，那麼接收方就能確認該數字簽名是發送方的。哈希值有固定的長度，運算不可逆，不同明文的哈希值不同，而同樣明文的哈希值是相同並唯一的，原文的任何改動其哈希值就會發生變化，通過此原理可以識別文件是否被篡改。

事實上，被篡改的經過數字簽名的數據電文很容易被發覺，甚至該文件在外觀上即可識別、無需鑒定，除非被告能夠提交不同內容且未發現篡改的經過數字簽名的數據電文。

『玖』 簡述一個典型的CA認證是如何實現的

目前互聯網實現身份認證主要是以個人證書，還有就是口令密碼等等形式來實現。 常見的身份認證安全技術有： PKI技術。PKI技術是基於公私鑰密碼體系的一種身份認證技術